ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)
-   -   New UI for LibAddonMenu r17 (update 1.6)? (https://www.esoui.com/forums/showthread.php?t=4269)

votan 02/04/15 01:42 PM

New UI for LibAddonMenu r17 (update 1.6)?
 
If it is time for a new revision for update 1.6, it is may also time for a refresh of the UI?

Does someone like it?

It is just some change to the main file: Making borders invisible, changing base class of the buttons, a bit wider....
Shall I continue and send the source code changes to sirinsidiator or should I go away? :o

sirinsidiator 02/04/15 03:55 PM

I kinda like the idea to change the look a bit to mark the beginning of a new era.
Maybe change the background to the one seen in the skill menu behind the categories?

I was also thinking about introducing toggleable addon categories and a search box to bring some order into the list when there are many addons installed.

As this library is used in so many other addons, I appreciate all input and I will do my best to keep it up to date.

Randactyl 02/04/15 04:11 PM

Having categories that we could set for our addons like on ESOUI would be kind of neat, though it would be somewhat unnecessary if a user only has a few addons.

Kind of makes me wonder if our settings library would need a settings panel of its own XD

sirinsidiator 02/04/15 04:14 PM

That's what I meant with toggleable. I would put a checkbox or icon somewhere above the list so you can switch it on when you need it. :D

Baertram 02/04/15 04:59 PM

I like the idea of a customizable look of the settings library addon too.

Possible options could be:
-Show categories
-Show search field
-Change font size & look in the addons list (if you got plenty of installed addons the list gets very long and reducing the font size by 2points would show more addons on one page e.g.)
-Maybe templates to choose from (like plugins for libAddonMenu). This way Votan could build a look he likes and use it and others can download and use the same, or just stay with the original one.

Imo this all is nice to have and I even like the current version like it is.
As human beings are lazy I guess the seach box or categories would be cool features ;-)

btw @Votan:

I like your new layout very much! The borders always kind of disturbed me

circonian 02/04/15 07:45 PM

I actually like the borders, at least some kind of divider between the addon name list & the panel.

But if were making suggestions the one thing I would really like to see is the ability to register sub-panels. Something like when you click on an addon name the list updates & you get a list of sub panels for that addon under it, rather than being restricted to only using sub menus.

Something like this:


When setting something to full width, checkboxes for example, it would be nice if the ON/OFF aligned to the right of the panel to allow for longer descriptions, no since in wasting that space. If were marking the control for full width it should be full width, not 60% width, in my opinion.

Garkin 02/04/15 09:05 PM

I personally do not like look of submenus in original layout, but other then that is fine. As for the new look I think that with divider between addon list and options it will look better.

But it should be possible to make menu skinable using the new ApplyTemplateToControl function and let user decide which template he wants to use.

BornDownUnder 02/04/15 09:26 PM

Quote:

Originally Posted by Baertram (Post 18635)
I like the idea of a customizable look of the settings library addon too.

Possible options could be:
-Show categories
-Show search field
-Change font size & look in the addons list (if you got plenty of installed addons the list gets very long and reducing the font size by 2points would show more addons on one page e.g.)
-Maybe templates to choose from (like plugins for libAddonMenu). This way Votan could build a look he likes and use it and others can download and use the same, or just stay with the original one.

Imo this all is nice to have and I even like the current version like it is.
As human beings are lazy I guess the seach box or categories would be cool features ;-)

btw @Votan:

I like your new layout very much! The borders always kind of disturbed me

I really like the idea of options for categories & font size, could also see a search function doing wonders as it is a pita to be scrolling down repeatedly when trying out different settings for overall compatibility in a unique UI setup.

The template idea is simply brilliant, I often used others' UI design as a basis then tweaked initially when I started out customizing UI in WoW, many years ago now.

For me personally, the borders I like, though increasing transparency of them would be nice. Perhaps time for LAM to have customizable setting options of its own?

votan 02/05/15 12:38 AM

Thanks to all, for the kind words. :)

A divider: Yes, I tried to get the look of the lore library already. (Not a border, but a divider) But it was a bit late I think :)

Own settings: Yes.
Allowing to change some perferences would be good. Another example: Allowing to colorize the buttons or not.
The question is: like the chat window (with the gear) or as part of the left-side list (easier: all there)

A bit more space for text: Yes. Aspecially german can be awful long. But that is true for all controls. Maybe word wrap?

@Garkin: Templates. Wow. Sounds great, but also a bit beyond my current LUA skills. And a bigger change than pimping the look. :D

Let's do it! Step by step and see how far we come.

First changes: here

Sasky 02/05/15 01:50 AM

Without the divider, for short addon panels it looks like the Author+Version string is about LAM not the addon. While a divider would help, it'd probably be even better to put it directly under the title.

Quote:

Originally Posted by circonian (Post 18636)
When setting something to full width, checkboxes for example, it would be nice if the ON/OFF aligned to the right of the panel to allow for longer descriptions, no since in wasting that space. If were marking the control for full width it should be full width, not 60% width, in my opinion.

How would they fit to the left of the text? If on the far right, there'd be a lot of space between label and control. The checkbox (or on/off) portion is fixed width though, and would be right next to the label.

As far as skins, there's a couple different levels. One would be the overall layout and the other would be the individual controls.

circonian 02/05/15 02:42 AM

Quote:

Originally Posted by Sasky (Post 18649)
How would they fit to the left of the text? If on the far right, there'd be a lot of space between label and control. The checkbox (or on/off) portion is fixed width though, and would be right next to the label.

As far as skins, there's a couple different levels. One would be the overall layout and the other would be the individual controls.

As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.

As for the Fixed width...Just change it and make it a different "fixed" width :p Make it just big enough for the words on the button, a little padding, & anchor it differently to allow for more room for text.

Although Your idea of putting the buttons on the left is probably a better idea.

If you guys come up with any ideas you want to implement & want any help with anything just let me know, I'de be happy to pitch in.

votan 02/05/15 04:07 AM

Ya, the problem I have with the "half" option is localization. Allowing/Enabling localization makes the definition of "isn't that long" very difficult. Text may small in english fitting "half" and when is squeezed in other languages.

One example always disturbing me a little bit:
Item tooltip:
"Bound upon equip"
=
"Wird beim Anlegen gebunden"

1.75x width. Causing a word wrap, effecting the line height on the left side, too.

Quote:

Originally Posted by circonian (Post 18652)
As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.


sirinsidiator 02/05/15 04:14 AM

Many good ideas! Keep 'em coming :)

I like the idea of using templates to change the style.
How about allowing two levels of customization?
  1. Allow the user to download additional style packages that change the default look of libAddonMenu
  2. Give addon devs a way to change the look of their own settings panel
That should cover all the things that where proposed so far and allow them without the need to update the main lib for every change in style.

For the settings I will have to use one of the methods proposed here.
  • Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.
  • Putting libAddonMenu into a standalone addon might look a bit inconvenient at first glance, but it would also open a few new possibilities.
    • Enables saved vars
    • Removes the need to bundle it with other addons and update every addon when a new version is released
    • Changes the load order so that the newest version of libAddonMenu is loaded first
    • Which in turn prevents problems like this

We could also add some kind of version check that allows us to put out a warning when libAddonMenu has not been updated and an addon requires a newer version.

edit: forgot about the subcategories...
I don't like them either. I think addon specific things should stay on the right side of the menu.
Maybe we can use tabs instead?

merlight 02/05/15 06:24 AM

  • I like the borderless look, fits better in the UI. Even better if you manage to give the add-on list a different background (like Achievements window, for example). If not, a vertical divider between add-on list and settings pane should suffice.
  • I don't like that a stand-alone LAM would be required. Somehow I got fond of how most add-ons bundle everything they need.
  • Categories... hell yeah! But there's a trap. ESOUI categories are too many, overlapping, and blurry. For me at least. There should only be a few.
  • While you're at it, please change CreateTopLevelControl to CreateControl in each and every control constructor: http://www.esoui.com/forums/showpost...99&postcount=2

votan 02/05/15 07:14 AM

For a large addon list we already know a lot techniques:
- recent list
- favorites (does it make sense here?)
- user-defined groups (but the users must organize themself)

Would work if we have saved settings, only

Automatic grouping:
- First Letter (A-D, E-H, G-M ...) sound easy, but can be tricky if you want the ranges to be dynamic.
- Author (Garkin would still have a large list :D) Does a user look for an addon by a specific author. No...

There could be some symbols (ESO works with symbols) or a dropdown, to switch view mode.

But we must be careful not to overload the effort with super duper high-end wishes.
I would start with a recent list and when grouping. Both optional and off by default.
Where must be something left for r18 :)

PS: I think it is dangerous and un-maintainable, that each control has its own revision mangement and basically can come from "anywhere".

votan 02/05/15 07:51 AM

I know what you mean, but if we keep the "embedded" style, I'm afraid, there is no choice.
If the namespace is unique, I think it's ok. And if where is a breaking change in future, you can use the version number for migration and swipe out.

Quote:

Originally Posted by sirinsidiator (Post 18655)
Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.


Ayantir 02/05/15 08:36 AM

Hi,

Posted Screenshot is nice.

Get the "ESO Menus font" at the left is really cool. No borders as real options in eso. I think the user need to think he's not into an addon setting but in its game settings.

As circonian says, maybe add submenus in the panel available as an option. I find them actually ugly, but they're needed. A revamp of them into the settings section is also needed.

Also for panel section make an embedded colorization (like my code snip below) with ZO_HIGHLIGHT_TEXT:Colorize

Lua Code:
  1. local panelData = {
  2.         type = "panel",
  3.         ....
  4.         displayName = ZO_HIGHLIGHT_TEXT:Colorize("pChat"),
  5.         submenus = true,
  6.         width = 600
  7.     }


When you reset to default, a reloadUI is done when 1 option get a reloadUI in its code.
In fact I think the whole options are set back to defaut, without loooking if the actual option is maybe at the default value. It could be interesting to fix this.


A Wider panel is absolutly needed ! In French and German, it's really hard to put comprehensive labels. English get a majority of little words, other languages not.
PS : A better way would be to manually set this option in addons (in panel section!) with an option like in my code above. It will set the width of the right section of the options. (without the addon list). if under your min val, ignored, if its the max set it for all addons. Some addons really need a very long list.


Try to fix the \n problem in description!
Wrote a description, put some \n\n and put something under you'll see the bug.

A search window for options based on labels
Look at pChat, it's horrible to set an option , as I got tons of options inside this addon. think Wykkyds got same problem.

If it's possible, try to implement back the dual colorpicker button. But it was a puddy tweak. I don't really know if it will be interesting. It's a label and 2 colorpickers. it returns r1, b1, g1, r2, b2, g2 instead of r, g, b

An option or something for rebuild LAM !
In some of my addons, a part of the option table is build by code, not manually set. In fact a got a block per guild. and when user join/leave a guild, I rebuilt LAM. but if the user has already get a look into LAM before, it won't rebuilt. Please have a look.

Add invisible option.
If LAM got "disable" value, could you see if invisible is do-able ? the option will get a true/false value required, built by one of our function as disable work. When 1 option control 10 others, invisible could be nice. controlled by SetHidden and maybe a smooth option if it's possible :p


For other suggestion.. Categorys, It's really a trap. I got an adddon GuildNotificator, It notifys in "chat", "guildmates" connexions. Does this addon go in chat, guild, both ? Could an addon be in 1+ category?
If we add those, I really think we need to add categories only if a category is populated by 2+ addons. If user only got 1 guild, 1 chat, 1 pvp, and 1 craft addons, it won't be displayed. But if he get 2pvp per exemple, categorys could be displayed. And a little checkbox at the top of the addon list "regroup Addons per category"

votan 02/05/15 09:22 AM

I have a similar problem. My unreleased solution (using Harven's Addon Settings) is to make EVERY configuration property able to be a callback. It's basically:
Lua Code:
  1. whateverControl:SetWhatEver(self:GetValueOrCallback(setting.whatever))
Every control is updated once the options fragment is re-opened or the selection has changed.
Harven's great implementation makes it smooth to do so.

GetValueOrCallback(arg) checks if "arg" is a function, and if so, calling it with "self", returning the value of the function. Otherwise returning "arg" itself.
In my case the number of controls is static, but for Ayantir a dynamic "setting.isHidden" could do what is needed to change the number of controls.

Quote:

Originally Posted by Ayantir (Post 18666)
An option or something for rebuild LAM !
In some of my addons, a part of the option table is build by code, not manually set. In fact a got a block per guild. and when user join/leave a guild, I rebuilt LAM. but if the user has already get a look into LAM before, it won't rebuilt. Please have a look.


Garkin 02/05/15 09:36 AM

After update to r16 because of Update 5, LAM doesn't properly select nodes in game menu tree when you open settings menu from slash command. Here is my (unfinished) solution:

Lua Code:
  1. --METHOD: OPEN TO ADDON PANEL--
  2. --opens to a specific addon's option panel
  3. --Usage:
  4. --  panel = userdata; the panel returned by the :RegisterOptionsPanel method
  5. local locSettings = GetString(SI_GAME_MENU_SETTINGS)
  6. function lam:OpenToPanel(panel)
  7.     SCENE_MANAGER:Show("gameMenuInGame")
  8.     zo_callLater(function()
  9.             local settingsMenu = ZO_GameMenu_InGame.gameMenu.headerControls[locSettings]
  10.             settingsMenu:SetOpen(true)
  11.             SCENE_MANAGER:AddFragment(OPTIONS_WINDOW_FRAGMENT)
  12.             KEYBOARD_OPTIONS:ChangePanels(lam.panelID)
  13.             for i, child in pairs(settingsMenu.children) do
  14.                 if type(child) == "table" and child.data.name == KEYBOARD_OPTIONS.panelNames[lam.panelID] then
  15.                     ZO_TreeEntry_OnMouseUp(child.control, true)
  16.                     break
  17.                 end
  18.             end
  19.             panel:SetHidden(false)
  20.         end, 200)
  21. end

It is not finished yet, because there is still one issue - it doesn't properly select button in addon list and scroll list does not move to that button. If I want to fix that, I will have to get reference for addon button. Probably the best would be adding it to panel itself. I have to try what I can do without extensive changes to the code.

EDIT:
Button is selected, but scroll list scrolls to the button only if button list is already initialized, when you open LAM settings for the first time it doesn't work.
Lua Code:
  1. --METHOD: OPEN TO ADDON PANEL--
  2. --opens to a specific addon's option panel
  3. --Usage:
  4. --  panel = userdata; the panel returned by the :RegisterOptionsPanel method
  5. local locSettings = GetString(SI_GAME_MENU_SETTINGS)
  6. function lam:OpenToPanel(panel)
  7.     SCENE_MANAGER:Show("gameMenuInGame")
  8.     zo_callLater(function()
  9.             local settingsMenu = ZO_GameMenu_InGame.gameMenu.headerControls[locSettings]
  10.             settingsMenu:SetOpen(true)
  11.             SCENE_MANAGER:AddFragment(OPTIONS_WINDOW_FRAGMENT)
  12.             KEYBOARD_OPTIONS:ChangePanels(lam.panelID)
  13.             for i, child in pairs(settingsMenu.children) do
  14.                 if type(child) == "table" and child.data.name == KEYBOARD_OPTIONS.panelNames[lam.panelID] then
  15.                     ZO_TreeEntry_OnMouseUp(child.control, true)
  16.                     break
  17.                 end
  18.             end
  19.             local scroll = LAMAddonPanelsMenuScrollChild
  20.             for i = 1, scroll:GetNumChildren() do
  21.                 local button = scroll:GetChild(i)
  22.                 if button.panel == panel then
  23.                     zo_callHandler(button, "OnClicked")
  24.                     ZO_Scroll_ScrollControlToTop(LAMAddonPanelsMenu, button)
  25.                     break
  26.                 end
  27.             end
  28.         end, 200)
  29. end

votan 02/05/15 03:00 PM

New version including code from Merlight and Garkin.

Pic 1


But this is nice, too. The title is right aligned.
Pic 2


Source here. Changes effecting panel and submenu.

QuadroTony 02/05/15 03:37 PM

two variants-ideas of list ofthe addons

1. scrollable list
2. pages, like 20 addons per page

Garkin 02/05/15 03:37 PM

If you are changing widgets, do not forget increase version number, otherwise it will not update older versions.

Lua Code:
  1. local widgetVersion = 7 --should be 8

votan 02/05/15 03:45 PM

Jep. link updated.

Quote:

Originally Posted by Garkin (Post 18682)
If you are changing widgets, do not forget increase version number, otherwise it will not update older versions.

Lua Code:
  1. local widgetVersion = 7 --should be 8


circonian 02/05/15 04:41 PM

Quote:

Originally Posted by votan (Post 18654)
Ya, the problem I have with the "half" option is localization. Allowing/Enabling localization makes the definition of "isn't that long" very difficult. Text may small in english fitting "half" and when is squeezed in other languages.

One example always disturbing me a little bit:
Item tooltip:
"Bound upon equip"
=
"Wird beim Anlegen gebunden"

1.75x width. Causing a word wrap, effecting the line height on the left side, too.

Quote:

Originally Posted by circonian (Post 18652)
As for the empty space, that is what "half" width is for, well one of its uses. If your text isn't that long use "half" width.

I was only referring to the question someone asked about what to do with all of the blank space between the description text & the button, if the description text is short. IF the text is short, then it should probably be using "half" width, but "full" width should actually be "full" width.

I'm in complete agreement with you, that is why I suggested the change. Somehow it needs to be more flexible.

circonian 02/05/15 05:04 PM

Quote:

Originally Posted by sirinsidiator (Post 18655)
How about allowing two levels of customization?
  1. Allow the user to download additional style packages that change the default look of libAddonMenu
  2. Give addon devs a way to change the look of their own settings panel
That should cover all the things that where proposed so far and allow them without the need to update the main lib for every change in style.

I like the whole template/style package idea, BUT I think a user downloadable version should be restricted to the background. Like whether or not you want to see the original libAddonMenu borders, or no borders, or a darker background.

My main concern is a user downloadable style changing something it should not that messes up the layout/look of the addon panel we create for our addons. For example what if I had two settings set to "half" width, but a user downloads a style that widens the buttons/droopdown box and now they no longer fit next to each other in "half" width. I wouldn't want them changing any color schema I set up for my panel either.


Quote:

Originally Posted by sirinsidiator (Post 18655)
For the settings I will have to use one of the methods proposed here.
  • Using the ingame savedvars to store the settings requires minimal change, but at the same time feels a bit wrong because it puts library related stuff in a file that is not owned by it.
  • Putting libAddonMenu into a standalone addon might look a bit inconvenient at first glance, but it would also open a few new possibilities.
    • Enables saved vars
    • Removes the need to bundle it with other addons and update every addon when a new version is released
    • Changes the load order so that the newest version of libAddonMenu is loaded first
    • Which in turn prevents problems like this

I'm not sure I get this, what kind of settings are we talking about saving?
The ingame savedvars is what I used for LibNeed4Research, but I admit I too didn't really like the idea of putting the savedVars in there.
However, since this is used by so many addons & every addon has to include it I think the standalone idea is a pretty good one.

Just force everyone to depend on it or add some way to check (without watching for it to load in OnAddonLoaded) to see if LibAddonMenu has been loaded AND what the current version is, before creating the settings menu. This way addons could create the settings menu or not, depending upon if LibAddonMenu is installed & if it is the correct/up to date version, so that the addon could function either way the user just wouldn't be able to change settings without it.

circonian 02/05/15 05:13 PM

Quote:

Originally Posted by Ayantir (Post 18666)
For other suggestion.. Categorys, It's really a trap. I got an adddon GuildNotificator, It notifys in "chat", "guildmates" connexions. Does this addon go in chat, guild, both ? Could an addon be in 1+ category?
If we add those, I really think we need to add categories only if a category is populated by 2+ addons. If user only got 1 guild, 1 chat, 1 pvp, and 1 craft addons, it won't be displayed. But if he get 2pvp per exemple, categorys could be displayed. And a little checkbox at the top of the addon list "regroup Addons per category"

Very good point and what happens when people start saying hey I'm going to put my addon in as many categories as possible so it shows up more to the user! It would just defeat the purpose of the categories. If categories need to be implemented it should not be up to the addon user what categories they are in. It should not be based on "features" but on something that allows each addon to ONLY fall under one category, for example some of the suggestions that have been posted, like a "recent" category or "A-D" "E-G", exc..just something that the addon dev does not get to choose multiple categories for, as much as some might say that is an unwanted restriction I think letting them choose might be worse.

circonian 02/05/15 05:15 PM

Quote:

Originally Posted by QuadroTony (Post 18681)
two variants-ideas of list ofthe addons

1. scrollable list
2. pages, like 20 addons per page

I like the idea of pages a lot better than categories, except maybe "recent" category.

Garkin 02/05/15 05:21 PM

Here is my update:

LibAddonMenu-2.0r17-Update6_beta.zip

- all widgets are now controls instead of top level controls
- submenu looks slightly different, label color now changes when menu is open/closed/mouseover

Randactyl 02/05/15 06:59 PM

Quote:

Originally Posted by Garkin (Post 18689)
Here is my update:

LibAddonMenu-2.0r17-Update6_beta.zip

- all widgets are now controls instead of top level controls
- submenu looks slightly different, label color now changes when menu is open/closed/mouseover

I like having the version and author right beneath the title. However, "Reset to Defaults" can look a bit orphaned especially on very short menus.

votan 02/06/15 12:23 AM

Quote:

Originally Posted by Randactyl (Post 18690)
I like having the version and author right beneath the title.

Within page or right-aligned?

Quote:

Originally Posted by Randactyl (Post 18690)
However, "Reset to Defaults" can look a bit orphaned especially on very short menus.

This could be a "feature", too. This way, the button is not clicked by accident :)

I like the idea of allowing to change settings away from default, if a "settings"-addon is installed, only.
Maybe allowing "styles" via activating different addons?

Changing the width (dynamic or not) of the right-side requires to change all controls, because the layout is hard-coded in every control without a master-width.
At this point, I wanted to wonder, if everybody is happy with this "thousand" files to include approach. But, if it is one addon only, this question is obsolete.

This would also reduce the size of the other addons and the "thousand" version checks at startup.

Randactyl 02/06/15 01:31 AM

Quote:

Originally Posted by votan (Post 18693)
Within page or right-aligned?

Within the page. Right aligned is too disjointed for my taste.

It's been a while since I messed with it, but I seem to recall an issue with addons only including the lua files for the controls they use. Only the controls included with the addon that loaded first (or the addon with the most recent version of LAM included) were loaded. If this truly is an issue, maybe a fix can be found to reduce each addon's footprint.

Really, I think the first question that needs to be answered is whether LAM is going to have its own settings panel and would therefor need to be an independent addon that is included as a dependency in the addons that utilize it. Because, as you said, this answer would help to determine the answer to other questions.

votan 02/06/15 02:11 AM

Just to clearify, what I am thinking about style addons:

Lua Code:
  1. --own version check
  2. local MAJOR, MINOR = "LibAddonMenu-2.0-classic", 1
  3. local lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  4. if not lam then return end  --the same or newer version of this lib is already loaded into memory
  5.  
  6. -- well known name registration
  7. MAJOR, MINOR = "LibAddonMenu-2.0", 17
  8. lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  9. if not lam then return end  --a settings addon is registered already

or

Lua Code:
  1. --own version check
  2. local MAJOR, MINOR = "LibAddonMenu-2.0-borderless", 1
  3. local lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  4. if not lam then return end  --the same or newer version of this lib is already loaded into memory
  5.  
  6. -- well known name registration
  7. MAJOR, MINOR = "LibAddonMenu-2.0", 17
  8. lam, oldminor = LibStub:NewLibrary(MAJOR, MINOR)
  9. if not lam then return end  --a settings addon is registered already

I would restrict additional control manipulation to what is possible with the setup data. This way an addon author can not work against the choosen style.
ANY settings addon author "just" needs to supply a compatible API and register to the well known name "LibAddonMenu-2.0".

I just have to finalize my thoughts. But now, I have to work first :)

sirinsidiator 02/06/15 03:28 AM

I was thinking about the following when I was mentioning two levels of customization:

The downloadable packages are things that change the style of the LibAddonMenu window without changing the layout.
For example removing the border, replacing the background, changing the used font and such things.
Maybe even change the size of buttons, but only inside certain restraints from the basic layout which is not supposed to change.

And the addon dev side customizations will allow to change the style and layout inside a panel in any way they want, but nothing outside of that.
e.g. align all buttons however they want, add an image to the background (only inside the panel)
They should not be able to influence the settings dialogs of other addon authors or the addon list in any way

I haven't looked into the technical details and limitations yet.

Categories are certainly hard to define in this case. I think if we where to use types, one addon would only be allowed to specify a single one from a predefined list.
Separating them by first letter or pages also sounds good. Maybe add all of these and allow the user to switch between them?

Settings would be things like which theme is in use, what is the current view mode of the addon list and other things that will probably come up over time.

I am also thinking about putting LibAddonMenu on github, so everybody can send me pull requests. This would make it a lot easier to integrate all the different ideas that you already seem to have started to implement. What are your thoughts?

Also one last note, I don't thing it is a good idea to change too many things at once when there are so many addons depending on LibAddonMenu.
We should take small steps and only put up one change at a time to see how it works with other addons.
For the launch of 1.6 we should only make the necessary changes to make it work and from there only add one new feature every one or two weeks.

Randactyl 02/06/15 03:42 AM

Ahh. Well, it's already possible to use custom controls. Why not use a similar system for library options?

First, we'd need to identify what LAM's settable options would be. Then, do something in LibAddonMenu-2.0.lua like:

Lua Code:
  1. lam.options = lam.options or {
  2.     isBorderVisible = false,
  3.     useStylizedLeftPanelBackground = true,
  4.     option3 = val,
  5.     option4 = otherVal,
  6. }
  7.  
  8. function lam:RegisterOption(key, value)
  9.     if lam.options[key] then lam.options[key] = value end
  10. end

The values in the options table could then be used instead of hard-coded values. I imagine some kind of refresh or reinitialization would need to be performed too.

Then you could distribute options addons dependent on LAM-2.0 rather than redistributing the whole library in different forms (and then having to maintain all of them when things need fixing).

LAM-2.0_classic.lua
Lua Code:
  1. local LAM = LibStub("LibAddonMenu-2.0")
  2.  
  3. LAM:RegisterOption("isBorderVisible", true)
  4. LAM:RegisterOption("useStylizedLeftPanelBackground", false)

It's late and I kinda feel like I'm rambling :) I'll come back after some sleep.

edit: this was in response to votan. sirisidiator snuck in while I was typing haha.

sirinsidiator 02/06/15 04:18 AM

Quote:

Originally Posted by Randactyl (Post 18698)
sirisidiator snuck in while I was typing haha.

I am a sneaky NB, so that's what I do :P

votan 02/06/15 04:34 AM

Quote:

Originally Posted by sirinsidiator (Post 18697)
I am also thinking about putting LibAddonMenu on github, so everybody can send me pull requests. This would make it a lot easier to integrate all the different ideas that you already seem to have started to implement. What are your thoughts?

Yes, this way corrections, like Ayantir, Garkin and Merlight did, could easier be merged than posting dropbox links :)

Quote:

Originally Posted by sirinsidiator (Post 18697)
Also one last note, I don't thing it is a good idea to change too many things at once when there are so many addons depending on LibAddonMenu.
We should take small steps and only put up one change at a time to see how it works with other addons.
For the launch of 1.6 we should only make the necessary changes to make it work and from there only add one new feature every one or two weeks.

Yes, I agree, I mentioned this already, maybe not clear enough :o
Just the changes we did, that is enough change already.

As every addon author has to switch to r17 this time, the policy of using shared addon or embedded files must be established now.
If not everybody must update everytime, more revisions can be released.

edit 1: And the callback thing Ayantir needs for the guild addon.

Baertram 02/06/15 09:13 AM

I like the template ideas to change the whole look of this library.

But allowing each addon author to individually change their addon's menu (inside the templates of the library) may result in blinking, attraction hunting menus (imo).
So I don't like this idea about background images, etc.

Like others have mentioned I'd prever a look that integrates into the game's menu style and won#t change that much in total.

BornDownUnder 02/06/15 10:06 AM

@ Votan, pic 2 of your post #21 looks great, apart from the lack of vertical alignment for the title with the right side of the drop-down menus, etc.

votan 02/06/15 10:37 AM

hehe, yes. :) But this heavily depends on the types of used controls. If it were checkboxes or colorpicker only, this would be true anyway. We better keep version 1.

Quote:

Originally Posted by BornDownUnder (Post 18710)
@ Votan, pic 2 of your post #21 looks great, apart from the lack of vertical alignment for the title with the right side of the drop-down menus, etc.


Randactyl 02/06/15 11:57 AM

Quote:

Originally Posted by Baertram (Post 18708)
I like the template ideas to change the whole look of this library.

But allowing each addon author to individually change their addon's menu (inside the templates of the library) may result in blinking, attraction hunting menus (imo).
So I don't like this idea about background images, etc.

Like others have mentioned I'd prever a look that integrates into the game's menu style and won#t change that much in total.

I agree. The more I try to think as a "typical user" the less I am interested in different visual options. A static style that fits in with the game is the more attractive option imo.

Also, I'm all for github too :)

sirinsidiator 02/07/15 06:51 AM

I got some feedback from Seerah and also the OK to change the license in order to put LibAddonMenu on github.

Quote:

Originally Posted by Seerah
As for the conversation on the forums about LAM... My two cents' worth:

A user should expect to download an addon and for it to "just work". This is why libraries get embedded. The "standalone libraries" usage is an "advanced users" concept over in WoW. That said, LAM and LibStub can already be installed standalone. ;) LibStub is about 1.5 kb and LAM is about 58.7 kb. You're not saving much on your hard drive by pulling it out of 10 addons to have it installed standalone. And LibStub will only load the files into memory to upgrade a version previously in memory. If the first addon loaded is the newest, then the others return out as soon as they start to be read. If, by the end of the loading process, more than one copy of the library has been loaded into memory, they'll be tossed at the first garbage collection cycle.

Libraries should not need saved variables. If a library needs saved variables, then the question should be asked whether it is a true library or an addon. Anything having to do with altering the look of the menu (templates, etc.) should be a separate addon. Most users won't care about that stuff, and fluff code like that does not affect the usage and purpose of the library itself. With it being a separate addon, you can then have a settings menu for it and saved variables.

Oh, and there shouldn't really be a need to save what panel you're looking at across sessions. Convenient for a dev that's constantly reloading, yes. But that's a fringe-case scenario and not something the general user is concerned with.

From a design standpoint, let me explain why the checkbox controls are as they are. LAM-1.0 used the game's own options control templates to create the LAM controls. When I made LAM-2.0, I kept them the same way so that they would be 1. consistent with both LAM-1.0 and with the default game settings, and 2. line up vertically with the other control types. If the general consensus is to make them different from the look of the game's settings, then so be it.

For votan's comment
Quote:

PS: I think it is dangerous and un-maintainable, that each control has its own revision mangement and basically can come from "anywhere".
The controls are in separate files than the main LAM core. To ensure that an older version of a control doesn't overwrite a newer one (because LibStub will only return out of loading the LAM core), they either have to register a version with LibStub or with LAM. I went with LAM so that it has full control over the controls. Also, other authors/addons can create their own control to register with LAM for their options. This could be contained in their addon, or a new library with addition control types could be developed.

Also, an addon only including a few control types shouldn't have an effect on another addon that depends on a different control because that addon should be including LAM and the control files as well. As mentioned above, the controls get registered through LAM, and LibStub will only return out of an older LAM core, not the controls.

Following this advice I suggest that we either take all the extra things that are not required and put them into a standalone addon that always contains the newest LibAddonMenu and keep the library itself as simple as possible or scrap them completely.

Style templates are probably something nobody would use anyways. Might be easier and more useful to just add a settings panel where you can set line width, choose between a few different backgrounds and that's it.
The second level of customizations is probably also a bit over the top. Might be enough to let addon devs choose the column width of the panel, so they can adjust the layout for different languages.

The categories are something we can do without save vars in the base version and once a user installs the proposed addon, it will save the state.

Some possible names for the new addon that come to mind are "AddonMenuEnhanced", "EnhancedLibAddonMenu", "LibAddonMenuPlus", but I am open for suggestions ;)

I'll set the github projects up later today or tomorrow.

merlight 02/07/15 07:44 AM

Yesterday I mocked up some automatic grouping by the first letter, displayed it using ZO_Tree... and it looked and felt awful. So I scratched that. :mad:

In the process I really struggled with the main controls' construction and what the word "panel" means in different contexts, so I started reorganizing that a bit, properly parenting controls where they belong, and also pondering moving some definitions to XML. When I'm done with that I'll try adding a search filter, that seems like a lighter and easier-done-right alternative to categories.

Garkin 02/07/15 09:16 AM

Quote:

Originally Posted by merlight (Post 18725)
Yesterday I mocked up some automatic grouping by the first letter, displayed it using ZO_Tree... and it looked and felt awful. So I scratched that. :mad:

In the process I really struggled with the main controls' construction and what the word "panel" means in different contexts, so I started reorganizing that a bit, properly parenting controls where they belong, and also pondering moving some definitions to XML. When I'm done with that I'll try adding a search filter, that seems like a lighter and easier-done-right alternative to categories.

I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

votan 02/07/15 01:51 PM

@Seerah/sirinsidiator:

Hopefully, we didn't misunderstood each other. :o
I like the idea of allowing to register custom controls.
What I meant is: If you want to update the core controls, e.g. to use a master-width, you have to update 13 versions (core + 12 controls). I have forgotten to update 2 extra versions already. And this could happen to others, too.
I meant: core controls should come from the core file been used.
If it is consens to copy 13 files over and over again, I accept it. I just wanted to talk about that.

If I understood you right:
- We keep the embedded style => stateless => no saved variables => no settings => no visual preferences
- embedded style => no xml

We updating the UI a little bit, adding the fixes from Garkin and Merlight and that's it, right?

Edit 1: And may find a solution for a large addon list.

Sasky 02/07/15 05:05 PM

Note that Wykkyd initially listed his framework as a require but since moved to embedded because it was unworkable. If Minion pulled dependencies automatically (already stated as a long-term goal)

As far as if it's still a library: that can be a bit loose with GUI and themes. See GTK+ for example.

Currently a separate addon could overwrite controls but not the settings menu. LAM could be refactored a bit to put the overall panel as a 'control' (in effect) to make it easily replaceable. That would allow external themes an entry to change the look of the overall menu.

As far as themes go, the easy way to switch between would be to only enable the addon for the theme wanted. Only one theme could be activated at a time, though. A theme manager could be implemented (again as a separate addon) and themes would register there instead of overriding LAM directly. I think this would be a bit overengineered, but it is an option.

Summary: default UI changes, add fixes, perhaps refactor the settings menu to be managed similarly to controls. Leave all theming as separate addons and no SavedVars from LAM itself.

sirinsidiator 02/08/15 07:09 AM

@votan: If it is true that you have to change every single file for something like the column width, it might really require some change in structure. But you also have to ask yourself how often a change like this really happens.
I will look into this once I had time to read the code of LibAddonMenu. I only saw bits and pieces until now so I can't really comment on it yet.

And yes. We let the library be a library and if we really want extra themes and saved vars and stuff, we put that into a separate addon which will augment the library.

What I actually wanted to say is, I just created the project on github: https://github.com/sirinsidiator/ESO-LibAddonMenu
Don't mind the eclipse project files and build directory. If you are interested in how to use them, I can write about it in a separate thread.

merlight 02/08/15 08:16 AM

Quote:

Originally Posted by Garkin (Post 18726)
I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

Damn you're right :x

ZOS_ChipHilseberg 02/09/15 08:47 AM

Quote:

Originally Posted by Garkin (Post 18726)
I'm not sure about XML - how do you want to update XML templates? I believe that you will just get an error that control has duplicate name.

If you're talking about modifying the children of a template then you'll have to set override="true" on them to have the XML attributes apply to the existing child (created by the inherited template) instead of trying to make a new one. This is new for 1.6.

merlight 02/16/15 08:21 AM

I've been playing with the settings window for quite some time, today I finally cleaned the code a bit, you can check it out here: https://github.com/merlight/ESO-LibAddonMenu/tree/edge (be warned though that I'm a rebase addict, so anything you commit on top of that might later go through painful merge conflicts)

First I have an important compatibility question

In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that? Because if the answer is yes and their motives are legitimate, I'm kinda screwed - I was pretty deep into the whole revamp when I realized this, I already had addon panels in a container and had just hopped onto OpenToPanel to make it work with everything else I changed.

Now the less important stuff...

I separated the LAM window from ZO_OptionsWindow completely, it now shows in LAM's own fragment. That's done by "inlining" the previously used function ZO_OptionsWindow_AddUserPanel and providing custom callbacks. I renamed CreateAddonSettingsPanel to CreateAddonSettingsMenuEntry (because that's what the function does), and only call it when the fragment is requested for the first time.

I copied RightPanelBackground and enlarged the window & option area accordingly, but didn't change any option control dimensions yet, so it looks awkwardly empty. Accidentally, I discovered votan's new style branch a few minutes ago, somehow I always forget to git fetch --all. I'll check that out later. (Actually I already have a few questions regarding votan's fork, but they're not LAM-specific so I'll create another topic for them later ;))

Addon list is now ZO_ScrollList, and there's a search filter box below it. Thanks to ApplyTemplateToControl (i.e. only on PTS) the box displays a hint when the box is empty, although I'm not sure whether it has suitable translations (SI_ITEM_FILTER_BY_TEXT is used in inventory item filter).

Edit: oh and panelData for RegisterOptionsPanel may contain additional .keywords for search, currently the filter searches addon .name + .author + .version. For example SousChef could set .keywords = "crafting provisioning", that way whenever I search for "craft" I get all addons with "craft(ing)" among their keywords, not only in their name. I should document that in source ;)

Garkin 02/16/15 10:07 AM

Quote:

Originally Posted by merlight (Post 18850)
I've been playing with the settings window for quite some time, today I finally cleaned the code a bit, you can check it out here: https://github.com/merlight/ESO-LibAddonMenu/tree/edge (be warned though that I'm a rebase addict, so anything you commit on top of that might later go through painful merge conflicts)

First I have an important compatibility question

In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that? Because if the answer is yes and their motives are legitimate, I'm kinda screwed - I was pretty deep into the whole revamp when I realized this, I already had addon panels in a container and had just hopped onto OpenToPanel to make it work with everything else I changed.

Now the less important stuff...

I separated the LAM window from ZO_OptionsWindow completely, it now shows in LAM's own fragment. That's done by "inlining" the previously used function ZO_OptionsWindow_AddUserPanel and providing custom callbacks. I renamed CreateAddonSettingsPanel to CreateAddonSettingsMenuEntry (because that's what the function does), and only call it when the fragment is requested for the first time.

I copied RightPanelBackground and enlarged the window & option area accordingly, but didn't change any option control dimensions yet, so it looks awkwardly empty. Accidentally, I discovered votan's new style branch a few minutes ago, somehow I always forget to git fetch --all. I'll check that out later. (Actually I already have a few questions regarding votan's fork, but they're not LAM-specific so I'll create another topic for them later ;))

Addon list is now ZO_ScrollList, and there's a search filter box below it. Thanks to ApplyTemplateToControl (i.e. only on PTS) the box displays a hint when the box is empty, although I'm not sure whether it has suitable translations (SI_ITEM_FILTER_BY_TEXT is used in inventory item filter).

Edit: oh and panelData for RegisterOptionsPanel may contain additional .keywords for search, currently the filter searches addon .name + .author + .version. For example SousChef could set .keywords = "crafting provisioning", that way whenever I search for "craft" I get all addons with "craft(ing)" among their keywords, not only in their name. I should document that in source ;)

I have just briefly checked code and it seems that you didn't read my comments to LAM.

- All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix.

- comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

- I don't like colorized addon names in the list. Any chance of using panelData.name instead of panelData.displayName or at least stripping color codes?
Warning: Spoiler


- panel.container should be probably anchored to panel.info (if exists), rather then to panel.label.
Code:

panel.lua:

- 107:        container:SetAnchor(TOPLEFT, label, BOTTOMLEFT, 0, 20+13)
+ 107:        container:SetAnchor(TOPLEFT, control.info or label, BOTTOMLEFT, 0, 20)

- addon panel is too wide. You should either change panel width or width of all widgets. Take a look to any submenu, it looks just ... not right.


A few changes are included in this version of Azurah. Azurah uses coustom made settings and even custom made widget, so it could be good compatibility test.

votan 02/16/15 11:01 AM

Quote:

Originally Posted by merlight (Post 18850)
In LAM r16- addon panels are top-level windows with their own background. That means they could be displayed directly with SetHidden(false). Are there any addons exploiting that?

I'm wondering myself, too. Because OpenToPanel handles that. :confused:
I think, we answer is "Basically, they could, but nobody does it (anymore)." :)

This version is also very nice. With better highlighting.

@Merlight: Can you test "SkyShards" with german displayname? Although the list is 10units wider than mine, there are ellipsis?!? 290 units would be good.

votan 02/16/15 11:09 AM

Quote:

Originally Posted by Garkin (Post 18852)
I have just briefly checked code and it seems that you didn't read my comments to LAM.

- All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix.

- comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

@Merlight: You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

Garkin 02/16/15 11:40 AM

Quote:

Originally Posted by votan (Post 18854)
@Merlight: You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

Or from the modified LAM included in Azurah (link in my previous post). I like my dropdown. ;-)

Seerah 02/16/15 12:40 PM

One thing to point out, that I don't think anyone ever took advantage of... The widgets/controls in LAM did not need to be used with the regular addon settings panels. You could use them as templates for any sort of display you wanted.

At least, this was the intention when I redesigned LAM for 2.0. Not 100% sure if any changes with the core made that moot...

http://www.esoui.com/portal.php?&id=5&pageid=10
See: LAM2 for the Experienced Author and Exposed Methods on LAM2

sirinsidiator 02/16/15 01:04 PM

@Garkin
Your half width height fix is already on its way in as well as some others mentioned in this thread. Once votan changed the thing I mentioned in my last comment on github I will merge his pull request and use it as base for further changes.

@merlight
Could you please keep the style changes and the search box for the addon list separated and also coordinate with votan in this ticket regarding the style changes. I will only be able to use one version in the end.

I would generally prefer if you could make tickets or use the few that I created for discussing the different changes and features that we are going to add instead of spreading everything into this thread, the comment section and pms ;)

merlight 02/16/15 01:16 PM

Quote:

Originally Posted by Garkin (Post 18852)
I have just briefly checked code and it seems that you didn't read my comments to LAM.

- All "half width" widgets in LAM have height set to 55 units. If you want to make custom widgets with different height, widgets will be incorectly anchored. See LAM comments where is possible fix.

Short answer to this and some other questions - I just ignored the option panels for this step. I knew there were some issues/fixes, but wanted to get the container window out for some feedback; the patch grew much larger than I anticipated.

Quote:

Originally Posted by Garkin (Post 18852)
- comboboxCounter in dropdown widget should be panel specific, otherwise you can get an UI error because of duplicate names when creating widget controls manually. Again, better explanation is in my LAM comment.

What's in a name? It is nor hand... I mean, does that combobox need to have a name?

Quote:

Originally Posted by Garkin (Post 18852)
- I don't like colorized addon names in the list. Any chance of using panelData.name instead of panelData.displayName or at least stripping color codes?

Sure. Forgot to revert that, I was flooding the list with dummy entries for testing and wanted to find actual addons quickly.


Quote:

Originally Posted by votan (Post 18853)
Can you test "SkyShards" with german displayname? Although the list is 10units wider than mine, there are ellipsis?!? 290 units would be good.

You can copy the function CreateOptionsControls and the whole Dropbox.lua from my branch in update6 https://github.com/votan73/ESO-LibAddonMenu

Quote:

Originally Posted by Garkin (Post 18855)
Or from the modified LAM included in Azurah (link in my previous post). I like my dropdown. ;-)


Ok I will install Skyshards, Azurah, any other notable addons that put stress on the menu?

Regarding CreateOptionsControls: I need to ask a few off-topic questions first.

... and while looking for a commit I saw earlier, another question @votan:
Do you use some automatic commit message "gluer"? I find the list of affected filenames in messages pretty inconvenient (moreso when it's at the beginning, pushing the interesting part to ...), also sometimes there's just the filename and the actual message follows on the next line, which requires a click to unfold on github.
Locally I use tig, it lists affected filenames itself along with how many lines have changed, and also shows only the first line in overview. So commits that don't say what they are on the first line are a mystery at first.

Garkin 02/16/15 01:31 PM

Quote:

Originally Posted by merlight (Post 18859)
What's in a name? It is nor hand... I mean, does that combobox need to have a name?

This is ZO_ComboBox template used in dropdown widget:
XML Code:
  1. <GuiXml>
  2.     <Controls>
  3.         <Control name="ZO_ComboBox" mouseEnabled="true" virtual="true">
  4.             <Dimensions x="135" y="31" />
  5.             <OnInitialized>
  6.                 ZO_ComboBox:New(self)
  7.             </OnInitialized>
  8.  
  9.             <OnMouseUp>
  10.                 ZO_ComboBox_DropdownClicked(self)
  11.                 PlaySound(SOUNDS.COMBO_CLICK)
  12.             </OnMouseUp>
  13.  
  14.             <Controls>
  15.                 <Control name="$(parent)BG" inherits="ZO_InsetBackground"/>
  16.  
  17.                 <Label name="$(parent)SelectedItemText" font="ZoFontGame" color="INTERFACE_COLOR_TYPE_TEXT_COLORS:INTERFACE_TEXT_COLOR_SELECTED" wrapMode="ELLIPSIS" verticalAlignment="CENTER">
  18.                     <Anchor point="TOPLEFT" offsetX="8" />
  19.                     <Anchor point="BOTTOMRIGHT" offsetX="-20" />
  20.                 </Label>
  21.  
  22.                 <Button name="$(parent)OpenDropdown" inherits="ZO_DropdownButton">
  23.                     <Dimensions x="16" y="16" />
  24.                     <Anchor point="RIGHT" offsetX="-3" />
  25.  
  26.                     <OnClicked>
  27.                         ZO_ComboBox_DropdownClicked(self:GetParent())
  28.                     </OnClicked>
  29.                 </Button>
  30.             </Controls>
  31.         </Control>
  32.     </Controls>
  33. </GuiXml>
As this template has named controls which use $(parent), they needs named parent. Otherwise all named children will have duplicate names.
Of course, you can create combobox without template, but it will be much more complicated.

Garkin 02/16/15 01:38 PM

Quote:

Originally Posted by Seerah (Post 18856)
One thing to point out, that I don't think anyone ever took advantage of... The widgets/controls in LAM did not need to be used with the regular addon settings panels. You could use them as templates for any sort of display you wanted.

At least, this was the intention when I redesigned LAM for 2.0. Not 100% sure if any changes with the core made that moot...

http://www.esoui.com/portal.php?&id=5&pageid=10
See: LAM2 for the Experienced Author and Exposed Methods on LAM2

Actually I have tried how LAMCreateControl works and I'm using it in FakeLibAddonMenu-1.0 (kind of LAM1 to LAM2 interface) and in the latest version of Azurah + Srendarr - I have created "subpanels" which are toggled by buttons on the top of the settings menu and all LAM controls are anchored to that panels.

You can see a little bit how it works on screenshots in spoiler in my previous post - there is active panel "Attributes" and pressing another button will show different panel with different set of controls. There is also visible custom widget "fontblock" which is pretty handy for font settings.

votan 02/17/15 02:54 AM

Quote:

Originally Posted by merlight (Post 18859)
... and while looking for a commit I saw earlier, another question @votan:
Do you use some automatic commit message "gluer"? I find the list of affected filenames in messages pretty inconvenient (moreso when it's at the beginning, pushing the interesting part to ...), also sometimes there's just the filename and the actual message follows on the next line, which requires a click to unfold on github.
Locally I use tig, it lists affected filenames itself along with how many lines have changed, and also shows only the first line in overview. So commits that don't say what they are on the first line are a mystery at first.

I use a subversion client, not github, so I don't have problems with multiline. I will stop this.

merlight 02/17/15 04:42 AM

Quote:

Originally Posted by sirinsidiator (Post 18857)
@merlight
Could you please keep the style changes and the search box for the addon list separated and also coordinate with votan in this ticket regarding the style changes. I will only be able to use one version in the end.

Sure, I will rebase before creating any pull requests anyway, so should be straightforward enough. Separating the search feature also makes sense.

Quote:

Originally Posted by sirinsidiator (Post 18857)
I would generally prefer if you could make tickets or use the few that I created for discussing the different changes and features that we are going to add instead of spreading everything into this thread, the comment section and pms ;)

Roger.


All times are GMT -6. The time now is 06:23 PM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI