Lazarus
Miscellaneous => Suggestions => IDE/CodeTools => Topic started by: x2nie on April 26, 2014, 11:08:23 pm
-
Hi ! :)
I've made a little modification in aesthetic aspect for Lazarus's Components Palette.
I can't go to bugtracker,
I've no much time yet to try and learn of how to create a manual patch,
So I send the code (2 x .PAS) here.
The idea is to add "margin" around the component list within Component Palette PageControl.
But, I also add a few other bugfixes such when the component list being resized / scrolled.
In theory, we only need to increase the BorderSize / BorderWidth of the ComponentLIst scrollbox.
But, it wouldn't happen since the borderwidth is ignored by any children that is Align=alClient.
We can solve it by adding a non-ignored border, with inserting a TPanel between the scrollbox and it's parent.
I wish it would help somebody who need to see improvement of aesthetic side of Lazarus.
Thanksyou for reading. 8-)
Regards,
x2nie
-
I've no much time to learn of how to create a manual patch,
so I send the code (2 x .PAS) here.
svn diff components/ideintf/formeditingintf.pas ide/componentpalette.pas > mypatch.diff
EDIT: And link, of course: http://wiki.freepascal.org/Creating_A_Patch (http://wiki.freepascal.org/Creating_A_Patch)
-
Thanks for the link, friend.
It helps me.
Very Nice, I have cleaned up the dead code, such as var "Rows" which is not necessary any longer.
So, what's next?
-
Great to see you taking an interest.
I can't go to bugtracker,
Why? What reason?
1) Balancing the margin, I assume this is done by
The main ide bar window can be adjusted in size (because Sizes of some elements actually differ in different widgetset (gtk, win, qt, carbon).
Therefore: any fixed margin will fix it for some people and break it for others. (Have you tested your margin on different widgetset?)
Also, since the scrollbox will resize to multi-line (if needed) and then glyphs are aligned to the top, I do think there is no problem with them being top aligned all the time.
IMHO it would be akward if they where sometimes centered (single line) and other time top aligned. (My 2 cents)
2) The "mouse/selection" pointer-button:
You are right this should not scroll. But your solution is not ideal either. Why adjusting its top coordinate on scroll. It should not be in the scroll box at all (same as the "list all tabs dropdown" button on the right hand site)
-
Great to see you taking an interest.
1) Balancing the margin, I assume this is done by
The main ide bar window can be adjusted in size (because Sizes of some elements actually differ in different widgetset (gtk, win, qt, carbon).
Therefore: any fixed margin will fix it for some people and break it for others. (Have you tested your margin on different widgetset?)
I can't go to bugtracker,
Why? What reason?
1) The good reason is because "we" need to do several test before proposing the patch to Lazarus team. Including test on "different" widgetset.
And I love to see other people report whether it is also fine in QT/GTK, etc. Due I only have GDI widgetset in my machine.
But, My real reason is: I never do that. I don't know how and where to report bugtracker. You know, often the difficult thing is in the first trying: how, why, when, where...
For example: Creating patch? I have no experience of doing it in before. Unfortunatelly Blaazen's command line didn't work for me, but he give us the link which is there is I found of how to create patch via Tortoise's Context-menu in Windows Explorer.
For honest, the reason is because I am a stupid newbie to do that. I don't know how, where, when. (When = is it now is good time to do?)
Hey,
I also unsure whether my idea is good enough to send to bugtracker,
IMHO, this "aesthetic bug" is in there so long, if the team let it there so perhaps it is "not a bug" in the Lazarus Team eyes.
Perhaps, they intended creating it by design. Perhaps the reason is yet known by you: "[size=78%]any fixed margin will fix it for some people and break it for others"[/size]
However, the top align buttons are looked like ugly in my eyes. So, I did it and let see Lazarus community proof my idea whether applicable or not.
Sure, my goal is to see Lazarus's Component Palette with balanced alignment in future release, if it possible.
Also, since the scrollbox will resize to multi-line (if needed) and then glyphs are aligned to the top, I do think there is no problem with them being top aligned all the time.
Unfortunatelly You can NOT do that. (or there is only me could NOT do that).
Scrollbox is not resizable, IDE's main form is not resizable, at least I can increase it height to see the multiline of the Component-Palette's scrollbox.
However, when the scrollbox is resizable, I will still provoke people to make it's margin balanced (top & bottom).
It is beautiful to see Lazarus as professional designed through it detail.
IMHO it would be akward if they where sometimes centered (single line) and other time top aligned. (My 2 cents)
2) The "mouse/selection" pointer-button:
You are right this should not scroll. But your solution is not ideal either. Why adjusting its top coordinate on scroll. It should not be in the scroll box at all (same as the "list all tabs dropdown" button on the right hand site)
You can't do it. AFAIK the Lazarus Team would not do it.
The select-pointer button is a TSpeedButton, all component buttons is also TSpeedButton.
Together, all of them share the same GroupIndex property so there will be only one button has "Down=True" property.
This all require both TSpeedButton & component-button in the same parent. We can't put them in separated parent.
I did you idea before creating this topic. And when we put select-pointer button outside the scrollbox, this button is useless in the way it unable to reset the component-button selection.
:)
-
I can't go to bugtracker,
Why? What reason?
1) The good reason is because "we" need to do several test before proposing the patch to Lazarus team. Including test on "different" widgetset.
And I love to see other people report whether it is also fine in QT/GTK, etc. Due I only have GDI widgetset in my machine.
But, My real reason is: I never do that. I don't know how and where to report bugtracker. You know, often the difficult thing is in the first trying: how, why, when, where...
For example: Creating patch? I have no experience of doing it in before. Unfortunatelly Blaazen's command line didn't work for me, but he give us the link which is there is I found of how to create patch via Tortoise's Context-menu in Windows Explorer.
For honest, the reason is because I am a stupid newbie to do that. I don't know how, where, when. (When = is it now is good time to do?)
Hey,
I also unsure whether my idea is good enough to send to bugtracker,
Ok, you want to discuss it before submission, that is fine.
The reason I asked is because it can easily be overlooked here on the forum. And that would not be wanted.
And also for the team, when we commit it to the SVN, then we can include the bug number, and we will always be able to look up what was the background for a change.
IMHO, this "aesthetic bug" is in there so long, if the team let it there so perhaps it is "not a bug" in the Lazarus Team eyes.
Perhaps, they intended creating it by design. Perhaps the reason is yet known by you: "[size=78%]any fixed margin will fix it for some people and break it for others"[/size]
However, the top align buttons are looked like ugly in my eyes. So, I did it and let see Lazarus community proof my idea whether applicable or not.
Sure, my goal is to see Lazarus's Component Palette with balanced alignment in future release, if it possible.
Well beauty lies in the eyes of the beholder. The opposite is true too.
I am not bothered by the current top align, but I am used to it for too long, to be a good judge.
[/font]
Also, since the scrollbox will resize to multi-line (if needed) and then glyphs are aligned to the top, I do think there is no problem with them being top aligned all the time.
Unfortunatelly You can NOT do that. (or there is only me could NOT do that).
Scrollbox is not resizable, IDE's main form is not resizable, at least I can increase it height to see the multiline of the Component-Palette's scrollbox.
However, when the scrollbox is resizable, I will still provoke people to make it's margin balanced (top & bottom).
It is beautiful to see Lazarus as professional designed through it detail.
Maybe your main IDE bar is already at maximum high? There is a max high restriction. Try to reduce the height.
Actually, I don't mind the center for the "all on one line" palette, If a good way can be found. But it needs to be carefully established how to do that.
Adding fixed extra margin, does not only most likely break with different widgetsets, it also will not work, if the window height is reduced, It may not work when docking, as again that may change the window size.
Then also where will the margin go, when it wraps to 2 lines? Does it push the 2nd line even further down? Meaning more scrolling.
So the only way, IMHO would be to change the margin as the window sive changes. I am not a fan of that, and further more, the margin would need to be removed, when you get the 2nd line. And That part, (having different margins for single and multiline) does not sound so good to me.
But I am happy to wait for feedback from others.
-----
Have a look at the attached, it shows the IDE bar, with 3 different heights, the biggest is the maximum
You can see that the toolbuttons (run/ stop, ...) also have distance to the bottom.
Ideally, it should be that the window was autosized, so there would be no extra space at the bottom (instead of inserting margins to distribute space usage)
I remember, this did not work when it was done initially. I do not know, if today it could be made to work on all platforms.
-----
To be honest, the bigger aesthetic issue as I see it is: The 2 line layout, so 2 tiny buttons to scroll, that (to me) looks so bad, and is so hard to use.
So a different overflow (maybe a drop down, like office toolbars do) would be nice.
Though I would run that idea past other team members, before going for it (and I have plenty other to do anyway)
Overall this needs more thought and feedback.
[/font]
2) The "mouse/selection" pointer-button:
You are right this should not scroll. But your solution is not ideal either. Why adjusting its top coordinate on scroll. It should not be in the scroll box at all (same as the "list all tabs dropdown" button on the right hand site)
You can't do it. AFAIK the Lazarus Team would not do it.
The select-pointer button is a TSpeedButton, all component buttons is also TSpeedButton.
Together, all of them share the same GroupIndex property so there will be only one button has "Down=True" property.
This all require both TSpeedButton & component-button in the same parent. We can't put them in separated parent.
I did you idea before creating this topic. And when we put select-pointer button outside the scrollbox, this button is useless in the way it unable to reset the component-button selection.
Ah I see.
It might work, if "all buttons up" is allowed, and there is code in the OnClick to take care of it?
" AFAIK the Lazarus Team would not do it."
Did anyone say so?
I will check if any one lese in the team has concerns about this. I am part of the team, and I would not be concerned. But before you do anything let me check
----------------
Btw: it may be a good idea to do individual patches, one per issue. That makes it easier to apply, and also each can be applied without waiting for the others.
MY trick to do that, is to have more than one svn checkout, so I can work in parallel.
-
Though I would run that idea past other team members, before going for it (and I have plenty other to do anyway)
Overall this needs more thought and feedback.
2) The "mouse/selection" pointer-button:
You are right this should not scroll. But your solution is not ideal either. Why adjusting its top coordinate on scroll. It should not be in the scroll box at all (same as the "list all tabs dropdown" button on the right hand site)
You can't do it. AFAIK the Lazarus Team would not do it.
...
"You can't do it. AFAIK the Lazarus Team would not do it."
Did anyone say so?
..... I am part of the team, and I would not be concerned. But before you do anything let me check
..
OOoops!
I am sorry, sir. I don't know if you are already one of the Lazarus Team.
So, my apologize, There was a misunderstanding, I don't really mean it.
Actually, while saying that, it's not about you nor about the team. Let me explain...
IMHO, What I were talking is based on in fact that the Lazarus IDE built upon standard LCL which are : TSpeedButton, TToolbar, TScrollBox, TPageControl, TMainMenu, etc. There is no special widget/widgetset that only used in Lazarus.
We know that this choice indeed for making sure of Lazarus IDE will be compiled together with any supported widgetst.
Meaning: Lazarus would always using standard (known) widgetset, so far: no special-widget I can found in Lazarus IDE codes.
Based on that thought, I am sure that my idea is ideal. Your idea isn't.
I think moving the "mouse/pointer/selection" button outside the scrollbox need some hack to have different behavior than it's standard usage.
That's why I reject your rejection.
When I refer to "Lazarus Team", it is in comparation to Borland Delphi IDE's team which they are cheating by using special class for Delphi IDE building.
In more detail, Delphi IDE seem built upon hacked TPageControl (it has no bevel in left, right, and bottom side). We can see these in it's Object Inspector, Text-Editor, Component-Palette that they uses special TPageControl.
This kind of TPageControl is not available in Delphi VCL.
Another fact is Delphi 7's dock. We couldn't find any class in Delphi distribution that has similar capability to it's IDE-Dock.
There is no dock-control that able to receive an object by 2 rows height.
Simply, Lazarus is not Delphi.
Delphi shipped with some custom-controls which are only available for it's IDE only.
Lazarus IDE seem would be always built upon known widgets (TPageControl, TSpeedButton, TToolbar etc) which are also available in Lazarus source code distribution.
Both have different approach, different reason, included different bug, and so on.
That was why I said "Lazarus Team would not do it (hacking behavior of such TSpeedButton by allowing shared GroupIndex in multiple parent)."
IMHO, Lazarus team need to keep the IDE to built upon any widgetset. Special widget would increase complexity of implementation for entire widgetset supported by LCL. Which is, not necessary, in my own oppinion.
--------------
However, I must change my mind, since told us whether overflow-widget for showing component-buttons is possible.
I have to say: Lazarus Team could do anything they want. Including the use of special (TSpeedButton) widgets if they think it would better.
Yeah, let's rock!
x2nie
-
Anyway, I found a new approach of how to correct the margin of Lazarus IDE Component Palette.
In my prior solution, I insert a TPanel between the TabPage/Sheet and the scrollbar. This panel is used to increase the margin (top, bottom, left, right).
This panel is drawn as white space around the scrollbox in Windows XP.
However, it might be drawn in unpredicable color when using different Windows XP theme.
And the very worst is in fact we don't really need the existence of this panel.
My new idea is not using any helper class at all, to increase the margin.
instead, we can refine the calculation of buttons's "realign".
First, We know that all component-button's Align = alNone.
The bounds is set manually by iterating for each buttons according to space available inside the scrollbox's Width.
This second option is more clean in visual appearance,
and would decrease the modification line compared with prior solution.
And the best of it is easier to adopt in any widgetset, due the modification is done in bounds calculation, no additional class required.
What do you think?
-
No need to apologize. You haven't done anything wrong.
Lazarus would always using standard (known) widgetset
Yes, but those standard widgets are painted by the OS.
So a TPageControl looks totally different on linux or mac or windows. ( http://wiki.lazarus.freepascal.org/Screenshots ), and the Pagecontrol uses a different amount of space.
Based on that thought, I am sure that my idea is ideal. Your idea isn't.
I think moving the "mouse/pointer/selection" button outside the scrollbox need some hack to have different behavior than it's standard usage.
That's why I reject your rejection.
It will take a few days to see if anyone has feedback, but one of the other Team Members (and I agree) pointed out, that changing the top while scrolling can cause flicker. Not on all Widgetset. Maybe not even at all today, but in future. (I have not tested it / this is only theoretical)
This is especially because (did not see that before)
OnPaint := @ScrollBoxScrolled; // Keep first button in visible areaOnPaint is the wrong place. This means it will lead to need to paint twice. So this is definitely out of the question.
Taking it out, simple means to add OnClick code. I would not call that a hack.
But yes taking it out, is substantially more work.
Neither solution is ideal though.
Taking it out will also mean
- In single line, if the window height is to small, and only half of the icons (half of their height) is visible), then all icons (single line) can scroll vertical, except the "selection pointer".
- If we later decide to replace multi line by some other concept, then we will not need the "selection pointer" in a separate parent any more.
However, the only "correct" way I can see to do this by changing "top" would be:
Have a standalone TScrollbar (that is not connected to the scrollbox. When it scrolls, you must FIRST change the top position, then scoll the box.
If you use the scrollbar that belongs to the box, then I am not sure you can guarantee this order.
Even if you find an event of The scrollbox that triggered *before* OnPaint, that may be to late. If the Scrollbox uses ScrollWindowEx, then the visible change is already made. And I do not know of any event, that is guaranteed to be before ScrollWindowEx (if used).
by allowing shared GroupIndex in multiple parent
Well it is not needed to be added to LCL. Code can be in the ONClick event.
---------------
BTW, if you extract your N-order versus Z-order patch. I think that can be applied
-
Anyway, I found a new approach of how to correct the margin of Lazarus IDE Component Palette.
Well implementation wise that sounds better.
But my concerns were behaviour related.
-
Anyway, I found a new approach of how to correct the margin of Lazarus IDE Component Palette.
Well implementation wise that sounds better.
But my concerns were behaviour related.
Also read my post on rather reducing the height to fit the icons.
But, as I said that was once prevented because window heights were wrongly calculated on some platforms. (And if this issue still exists, then calculating the margin based on the height, may lead to the same bug).
Unfortunately, I do not know if that issue still exists. And unless we find some one who knows, I rather not touch it (Some one else in the team might...). So this will be up to finding someone with more knowledge on this particular issue.
-
Isn't the delphi's default behavior acceptable ee a horizontal scroll instead of a vertical one? What made you decide to use a vertical scroll on what it looks like a single line of icons? It is counter intuitive but then again I do have a delphi background so......
-
I don't have a delphi that old, that it still has a component palette in the main bar.
I only have the turbo explorer, and that has the components in a separate window, as a listbox, rather than toolbar.
So I dont know.
But if it was a horizontal scroll, then where to place the scrollbar? It would need to be below the icons, spanning the entire width of the tabsheet. So that would mean you need more height to have one line of icons + a scrollbar below?
Overall, this kind of embedded palette is not ideal in many ways. Maybe instead of doctoring on it, it would be nice to find a replacement?
Look for example how they are organized in other IDEs
http://gihansblog.files.wordpress.com/2011/08/screenshotofglade.png
-
Here you have screenshot how it is invented in Delphi7.
EDIT: It is in Wine. As you can see, when palette is longer, Delphi will add a small button to the end which show a pop-menu with exceeding controls.
EDIT2: I don't like this. IMO Lazarus solution is better. 8)
-
Hi, Taaz, Martin_fr, Blaazen, ...
Delphi 7 uses TPageScroller, not a TScrollBox.
TPageScroller no need any TScrollbar at all. For scrolling, TPageScroller will show the arrow on right or left (surrounding with red rectangle in my attachment) when there is any control hidden behind.
So, Taaz, you will never see its behavior in Lazarus, due there is no availability of such class in Lazarus/LCL, which is identic to TPageScroller
Overall, this kind of embedded palette is not ideal in many ways. Maybe instead of doctoring on it, it would be nice to find a replacement?
I agree. Let we see what have been done by people:
1) Tabbed Page.
The one we are disscussing, used by Lazarus, MSEIDE, VFD/fpGui designer, and early versions of Delphi.
it also called as Ribbon in Microsoft Office 2007/2010.
It is fine, but we able to see one row only.
So, we need to replace it with something able to show multiple rows of components.
2) Chevron.
Additionally, In Delphi 7, there is a chevron button (surrounded with blue box in my attached picture) that when clicked it would show all component palette contained within the current page, as menus (as also shown by Blaazen).
3. Accordion
Look for example how they are organized in other IDEs
http://gihansblog.files.wordpress.com/2011/08/screenshotofglade.png (http://gihansblog.files.wordpress.com/2011/08/screenshotofglade.png)
Glade (GTK GUI builder), VisualStudio, and modern Delphi are using it.
It takes large area in IDE, which is I want to avoid.
If Lazarus use it someday, it should an option to get back the PageControl (as current lazarus)
4) Drilldown.
I think, It would also useful when we can implement Martin's idea: showing overflow container like office 2007's Shapes super-combobox.
screenshoot: http://office365.pcpro.co.uk/sites/microsoftoffice365/files/styles/insert_main_wide_image/public/Create%20diagrams%20Figure-6.gif (http://office365.pcpro.co.uk/sites/microsoftoffice365/files/styles/insert_main_wide_image/public/Create%20diagrams%20Figure-6.gif)
It is similar as TCombobox, but TComboBox has only one item, while we need to show several items per row.
5. ScrollBox
It is used by current Lazarus, together with components's PageControl.
This way, a scrollbar will shown in the right side when any component button is hidden.
Compared with Delphi 7, the Lazarus IDE's Scrollbox is easier for scrolling items, due ScrollBox shown one scrollbar, so we no need to move mouse to go back to prior row.
When in Delphi 7, 2 arrows are shown, we need to move mouse to left side or right side which is not simple.
What do you think ?
---
Edit: TPageScroller, not TScrollPage
-
That is also what many office suites do. IMHO also a good solution.
Even better, if it can be detached, and stays open as a window. Otherwise it is a lo of work, if you need to open it over and over again.
BTW: changes may need to be tested with:
EnableComponentPaletteOptions (define when building the IDE)
It is an unfinished attempt (*NOT* by me, I cant take the credit) to add configurable ordering. (hint open options, use drag and drop in options)
-
Delphi 7 uses TScrollPage, not a TScrollBox.
Also nice. But more work to scroll. (especially if you often need to switch between to items not fitting on one page.)
It can be implemented, using 2 toolbuttons. (Add to LazControls, or directly in the IDE)
What do you think ?
Personally: I am not a fan of TScrollpage.
But I would accept it, if some one would implement it.
Just a hint, scrolling one by one may be slow. So maybe scrolling half/full page, or have 2 buttons with different speed, or allow click + shift key, ..... just ideas)
---------------------
Most other solutions are fine. Getting rid of scrolling IHMO a good idea.
Being able to detach keep open any dropdown: Nice addition, but not a must.
e.g
having (both)
a) none scrollable, single line, +chevron in the main bar. (though, if it has chevron, it may as well have 2 buttons to scroll sideways)
b) additional window, that can be used optional, containing Accordion
together, would be perfect.
But that is just my 2 cents.
And other solutions are very acceptable. After all, if x2nie volunteers to do more on that, you get to have a choice too. (Just describe it before you do it, so it is somewhere in range)
-
On newer delphi version (up to delphi 2007 after that I stopped upgrading) you could set the palette to horizontal by checking or unchecking some option but each category was autosize to show all the icons the horizontal scroll bar was scrolling everything including the category containers as if they where a bunch of TgraphicControls with variable number of icons/component inside a tscrollbox. The layout auto placement wend first down then right.
If and I stretch this as much as possible if any one is going to work on the GUI part of the IDE then you must keep in mind that the current layout is awful in windows 8 default theme. It requires a tone more space than on win7, they wend and raised the border size from the classic 2 pixels on each side to around 10 on each side that makes the floating window layout a waste of space, a lot of space and take in to account that the various border styles (bstoolwindow/bsdialog/bssizeable) are no longer distinguishable and everything looks the same you get a pissed of developer.
I'm so pissed with the "new" look that I started working on a custom tabs control that will eventually be used on a custom tpagecontrol which will allow me to define some empty space on the tabs and use it as a caption bar on my applications to allow me to set the border style to bsnone and I will manually handle resizing and moving. Attached my current desktop.
-
Okay, while we are waiting for someone else, let's step any possible progress.
---------------
BTW, if you extract your N-order versus Z-order patch. I think that can be applied
Here, in attachment.
-
@taazz
Slightly OT, but I'm intrigued as to why you choose an OS that annoys you and hinders code development, or requires time and effort to code workarounds for display issues. What is the compelling reason for your OS choice, then, given the myriads of alternatives? I'm not having a go at you, I'm genuinely interested in (possible) advantages of Win8 over its predecessors and non-Windows alternatives.
-
While reviewing the patch, I also found a bug in the existing code.
Buttons per row did not take into account the space used by the scrollbar (you found that too).
But you over corrected it. If all fit into one row, then that space can be used.
I made a tiny change to that. I will commit to SVN soon.
BTW with what name should I enter you in the contributor list?
-
Buttons per row did not take into account the space used by the scrollbar (you found that too).
But you over corrected it. If all fit into one row, then that space can be used.
Can be used for what?
I made a tiny change to that. I will commit to SVN soon.
BTW with what name should I enter you in the contributor list?
:-[ Well, I think "x2nie - Fathony Luthfillah" would be good recognized by my both friends and family.
Only a few of friends knew my real name, and my family never know that I used a strange name in net.
-
See my commit to svn.
Also see
http://bugs.freepascal.org/view.php?id=26083
So on windows it will be incorrect for now (but it was incorrect before)
-
Ohyes. I got it. I could see that.
I think it is (logically) better now, except the bug of ClientSizeWithBar you just found it.
Thanks you very much. I need go home now, see you again soon.
Regards,
x2nie
-
And http://bugs.freepascal.org/view.php?id=26084
-
And http://bugs.freepascal.org/view.php?id=26084
Which is fixed in the meantime :)
-
... if any one is going to work on the GUI part of the IDE then you must keep in mind that the current layout is awful in windows 8 default theme. It requires a tone more space than on win7, they wend and raised the border size from the classic 2 pixels on each side
...to around 10 pixel-width on each side that makes the floating window layout a waste of space, ...
Yes, the prior taazz's screenshoot talks show the fact.
From that, I have a conclusion: The scrollbox (of component-palette) is a victim from the difference of Tform's border width dictated by different OS.
In other word, Lazarus IDE has wrong aesthetic calculation of Main IDE's form.Height.
This way, the Height of form is fixed; the border width of form is unpredictable; this affect ot scrollbox's Height of being the residue of available space.
pseudo : Scrollbox.Height = Form.Height - MenuBar.Height - (BorderWidth * 2 {topBorder+bottomBorder}).
Meaning Scrollbox's Height is affected by borderwidth, twice !
Meaning Lazarus has different ComponentPalette's Height between XP and Win 8. Possibly different in other theme or OS.
So far, its not a big problem in any OS, any Theme, any Widgetset,
It was proofed by such Taazz experience in Windows 8 which has the most biggest borderwidth, and component buttons is in good visual appearance.
But, while my current concern is the aesthetic perspective start from my own experience with Windows XP & Windows 7.
It looked like ugly to have extra margin in the bottom side of scrollbox; due XP takes only 2 pixel while Win 8 takes 10 pixel for each side of form border.
----------
Today, it seem easier to identify what is going on and what is expected as solution.
1. Component palette should be fine when implemented in any widgetset
2. CP should be fine in any theme (including Windows 8 default theme, plus 10pixel borderwidth of main IDE form)
3. (and it is my concern) component palette should vertically centered by providing balanced margin on top and it's bottom
IMHO, it will be done in several solutions / ideas.
1. We don't need to worry about widgetset; Because the different implementation is in the TPageControl, not in TScrollBox.
We have no problem about TPageControl of ComponentPalette, so we leave it as is.
But we will continue enhance the aesthetic in TScrollBox which is it has identical implementation in all widgetset.
2. When the active OS's theme changes the entire ClientHeight of the IDE mainform, additional border width will reduces scrollbox.Height,
so maybe, it is the best time to make sure the scrollbox is in still good condition
by correcting / recalculate the constrains MaxHeight of the form.
Example: current lazarus's component palette is good enough in Win 8, but what will happen if other theme has more than 12 pixel borderwidth?
We must able to avoid the ScrollBox to be too small.
But it was done in current Lazarus, by providing extra space solution that will be used in such Taazz's screenshot.
The only small bug is in the aesthetic /visual perspective. It need small adjustment, IMO.
3. The big mistake about Top Alignment of component-buttons is thinking that their Align is alTop. No, it's wrong. Nor: Align = alLeft !
When we look at codes, all buttons are manually positioned by button.SETBOUND(x, y, button.width, button.height)
Meaning that we have a chance to positioning button in anywhere we want, including to put it vertically centered within the scrollbox.
----------
Anyway, about additional idea such chevron, super-combobox showing all component in multi line in popup container,
accordion and so on, is in different expectation IMHO.
My current focus is about the current Component Palette located in MainForm, by the reason of it is always visible.
Every time we start Lazarus, we see it (component palette) which is in my eyes need "final touch" in it's layout design.
So it is the highest priority before providing extra features which are not shown in IDE main form.
Indeed, we can continue discussing that idea; but let me proof that my first idea will be fine, as it was expected.
Today, it is clear that making the buttons in vertical centered inside the scrollbox would not mess the widgetset implementation;
because there is nothing to ask widgetset about the bounds (left, top, width?, height?). All done manually hardcoded.
-
component palette should vertically centered by providing balanced margin on top and it's bottom
If that is possible, then it should also be possible to adjust the form height (auto size) for each OS/Version. With the correct form height there would be no need to add a margin for making it centred.
As I said, I remember being told that there is/was a bug preventing this. Not sure who knows the answer.
Currently Having no top margin has a big advantaged:
- When wrapping, I can see the top of the 2nd line. Adding another indicator that there are more items (the scrollbar is very tiny, and easily overlooked)
- Yet true, one can see, that this half visible line is even more ugly. And that it should always scroll to full lines, and show exactly one full line only.
One could also argue that v-centering the components, will look akward, as the toolbars (load/save/run button) are all top aligned.) This will especially be the case, if the required margin for centering is bigger. See my mock-up, I find this very unbalanced.
So "good looking" is subjective too.
------------
Anyway, I will not object to it, if any other team member wants to add your patch to center them to the IDE.
I am not sure, if all developers read here. They definitely are on the mail list.
------------
I will be happy to discuss and help getting a patch into SVN that will keep the "selection cursor" item visible, if lines are scrolled.
But the current approach (adjusting top in OnPaint is wrong)
At the time of any event from the scrollbox it is to late to update the top coordinate.
E.g. on Win32 ScrollBox uses the WinApi call "ScrollWindow" which acts immediately. So the scroll will be visible on the screen, before you can change the top coordinate.
On fast computers that may not be noticeable. But on slower PC that will flicker. (There is also a bug, that may currently prevent or reduce flicker, but once that gets fixed ...)
So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.
Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.
Feel free to discuss that, if/before you want to to anything on it.
-
component palette should vertically centered by providing balanced margin on top and it's bottomOne could also argue that v-centering the components, will look akward, as the toolbars (load/save/run button) are all top aligned.) This will especially be the case, if the required margin for centering is bigger. See my mock-up, I find this very unbalanced.So "good looking" is subjective too.------------Anyway, I will not object to it, if any other team member wants to add your patch to center them to the IDE.
The art is subjective and doesn't require any logic for being exist. This one is very subjective.
But anything in aesthetic world is measurable. Margin is measurable, being centered is measurable.
Aesthetic is about why, art is about how.
Aesthetic is about function while Art is it's fashion.
http://en.wikipedia.org/wiki/Aesthetic#Aesthetics_and_the_philosophy_of_art
The weird thing IMHO is to judge: in where area the DESIGN can be found? is design = aesthetic or it is an art?
Meaning if we escalate the problems, we met big pain.
So, let we solve all task case by case. One by one. Don't let all good plan aborted by contesting problem each other.
I don't say that you did it, but I notice you that we might going to that.
------------
The Run button, Save, Save All, Stop, Pause, Open... etc. Button are top aligned; and it yield extra space in it's bottom side,
which is seem also ugly in my eyes. But this buttons are inside TToolbar, not in TScrollBox (like component buttons).
We can no nothing to positioning the Toolbar's button. But we can set bound the component button.
I think, the toolbars is already multiline (2 rows of toolbar in IDE), so for additional empty area in the bottom of toolbars, will always be easy recognized as extra space because the toolbar is top align.
While in the component palette: it seem expected as always single line, plus the buttons is "seem" as left aligned, meaning extra space should be in right side, not bottom side.
Same cases:
http://bugs.freepascal.org/view.php?id=24118
http://www.turbog.com/wp-content/uploads/2013/04/haiku_lazarus.png
http://4.bp.blogspot.com/-9iIXo5X4LEw/UVjWGwWUI5I/AAAAAAAAAbY/TmmtdiY3tZ4/s1600/Captura+de+tela+-+31-03-2013+-+21:34:01.png
http://blog.marcelofernandez.info/wp-content/uploads/2010/06/Lazarus_IDE_GTK1_Linux.png
http://2.bp.blogspot.com/-iw5SwXZwBEc/UYpCNenH6wI/AAAAAAAAAtM/DWoKFkhhrkA/s1600/Lazarus-running-on-Ubuntu-1.gif
Meaning the component-buttons seem as need "final touch" which is cleaning up the wrong area ( = make them centered vertically).
And toolbars are : seem well designed already; otherwise, we need to rethinking about how to center-aligning the toolbar?
Maybe the perfect as you are expect would to get rid from toolbar at all. We can reposition all (Run, Save, Open,..) button (distributed vertically) as what has done with component buttons (Menu, Button, Edit, Label, ...), by manually call SETBOUND
--------------
I disagree:
...
On fast computers that may not be noticeable. But on slower PC that will flicker. (There is also a bug, that may currently prevent or reduce flicker, but once that gets fixed ...)
So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.
Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.
We must avoid flicker by look at the detail. At least, flicker is under tolerance when not occurs repeatedly.
Again, move the arrow button outside the scrollbox whould excalate the problem. The selection of component button is not only used inside one unit.PAS, there are several units accessing of which button being down.
Another reason is there are no such OnClick. instead there are OnMouseDown, OnMouseUp, OnDblCLick.
And it is going to more complex while hacking the behavior of the buttons : when knowing there is Multi-Select mode when user Shift+Click on one of component-buttons.
----------------
However, when LCL could adjust client are by setting such BorderWidth = 5, it would solve both toolbar + scrollbar's aesthetic bug.
But it seem will never happen due LCL kept compatibility with Delphi behavior.
So, we need to look for other solution.
What do you think ?
-
Hi guys,
About multi-row implemenation of Component Palette, what's your oppinion about CodeLite ?
http://hative.com/wp-content/uploads/2013/10/free-ides/free-ide-codelite-6.jpg
-
Another reason is there are no such OnClick.Speedbutton has an onClick. But of course the change would need testing. And yes it would be (much) more work.
Anyway, in order for me to accept a patch, I must be convinced it has a certain (basic) correctness.
Of course I am not the only judge to that. If any other member of the team believes that the patch is good, then they can apply it. (I will not stop them, but I will make them aware of my concerns. If they think my concerns are unwarranted, then fine.)
I told you what I think. It is up to you to run this with other team members. You find more of them on the mail list.
The rest of the team may have different opinions. I do not know.
-
Hi guys,
About multi-row implemenation of Component Palette, what's your oppinion about CodeLite ?
http://hative.com/wp-content/uploads/2013/10/free-ides/free-ide-codelite-6.jpg (http://hative.com/wp-content/uploads/2013/10/free-ides/free-ide-codelite-6.jpg)
It looks like the newer Delphi horizontal palette I don't dislike it per see but it makes me grind my teeth a bit. I guess I'll get used to it in time.
-
Oh, please NO!
Bart
-
Another reason is there are no such OnClick.Speedbutton has an onClick. But of course the change would need testing. And yes it would be (much) more work.
Anyway, in order for me to accept a patch, I must be convinced it has a certain (basic) correctness.
I mean in ComponentPalette.pas, the component-buttons (TSpeedBUtton) are not using OnClick.
Oh yeah, you know it need more test. I am in the middle getting a try of several solution of keeping the arrow-button in home while scrollbox being scrolled.
IMHO your second option (create new TScrollBox class) seem would be the best rather than first option (move arrow-button outside the scrollbox).
When It were done, I will send the patch.
@Taazz, @Bart: ha ha ha! that is funny. I never know in before, if Delphi could be like that.
Thanks!
-
They do not have to use OnClick
The onClick simple needs the code to set (they can do it in on mouse down too)
ActiveSpeedButtonInOtherParent.Down := False;
To simulate they are in one group.
Then of course anything that accesses TheTabsheet.Controls must adjust the index by one, as one item is no longer in there.
--
If you look at TScrollBox, it uses ScrollWindow (google msdn + scrollwindow), so it needs less repaint.
However for the component palette, and given that this is fairly small, this is not a must.
-
Here goes how seldom I use the designer, there is Menu > View > Components an alternative way to access the palette.
-
Here goes how seldom I use the designer, there is Menu > View > Components an alternative way to access the palette.
That dialog can also be accessed via right-click on component button, and then "View All" on pupup menu.
Martin, I have problem:
In ComponentPalette.pas (ide.lpk) I added this:
type
{ TScrollBox }
//Helper class (interceptor) used for keeping first button always in home when scrolled
TScrollBox = class(Forms.TScrollBox)
private
FOnScroll: TNotifyEvent;
protected
procedure WMVScroll(var Message : TLMVScroll); message LM_VScroll;
public
property OnScroll : TNotifyEvent read FOnScroll write FOnScroll;
end;
Then error occurred in compiling with message: Identifier not found "TLMVScroll".
But IDE package doesn't depends on LCL package.
In your oppinion, in where unit/package I should declare that class?
PS:
Now I know whats you refer to
So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.
Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.
Feel free to discuss that, if/before you want to to anything on it.
-
But IDE package doesn't depends on LCL package.
The IDE is not a package. It is a project (and as such depends on LCL)
At least on Windows LM_VScroll will be before the scroll.
The worry is gtk2. There are so many gtk2 versions... But I am not a gtk2 expert.
-
But IDE package doesn't depends on LCL package.
The IDE is not a package. It is a project (and as such depends on LCL)
come on... there is \lazarus\ide\ide.lpk; it depends of SynEdit, codetools, IDEIntf.
I think there was a reason to keep it not depend to LCL directly.
But I aborted to use it, and now trying another solution: to move arrow-button (it named SelectButton) to outside of scrollbox.
Okay, don't worry. Let forget it.
8-)
-
Ok, you should work on trunk, so your patch will not miss out changes in trunk.
In trunk ide.lpk does not exist any more.
ide.lpk, was a temp solution, that was ONLY for compiling the debugger test case.
Please open ied/lazarus.lpi, and ignore the package
-
Is it? Ah, How idiot I am.
So, I have arrived on my bottom line.
I did it: copy-paste per file required from trunk --> to C:\Lazarus %) :P
Oops!
I don't know how to compile Lazarus source code. Really.
Is there a link I can follow to compile Lazarus from source code in better way?
(sorry, if its out of topic).
Thanks you.
-
Is there a link I can follow to compile Lazarus from source code in better way?
It's not because I am lazy. It was because I failed in early trying.
Oke, I found a great and easy step I could follow within \Lazarus\Docs\Install.txt :
3.1 Installing Lazarus under Windows:
...
You have to download the Lazarus source:
ftp://ftp.freepascal.org/pub/fpc/source/lazarus.zip (ftp://ftp.freepascal.org/pub/fpc/source/lazarus.zip)
Then unzip it to c:\lazarus for example.
You have to install at least FPC 2.6.2, e.g. in
c:\pp\bin\win32.
In this directory you can find a lot of exes (make, grep, ppc386, and so on).
Open a command line. Start->Run...>command or choose MS-DOS icon.
Type:
cd c:\lazarus
rem of course adjust to your path:
set path=c:\pp\bin\win32;c:\lazarus
make
If you are lucky then you can type: lazarus.exe
8-)
-
1) to build lazarus you have 2 choices
a) open the file "<LAzarus_Install_Dir>\IDE\Lazarus.lpi" as martin already suggested and press build.
b) use the menu "tools\Build Lazarus" inside your IDE.
2) Never rely on .zip files when trying to create a patch or work on some code it is better to check out the source directly from the SVN repository use turtoiseSVN its the easiest svn client, just right click on a folder and select svn checkout type in the svn server and you are good to go even for patch creation.
-
Hi taazz!
Yes, I am familiar with Tortoise. And I have a good and small patch here.
------------
I will be happy to discuss and help getting a patch into SVN that will keep the "selection cursor" item visible, if lines are scrolled.
But the current approach (adjusting top in OnPaint is wrong) At the time of any event from the scrollbox it is to late to update the top coordinate.
E.g. on Win32 ScrollBox uses the WinApi call "ScrollWindow" which acts immediately. So the scroll will be visible on the screen, before you can change the top coordinate.
On fast computers that may not be noticeable. But on slower PC that will flicker. (There is also a bug, that may currently prevent or reduce flicker, but once that gets fixed ...)
So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.
Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.
Feel free to discuss that, if/before you want to to anything on it.
Hi Martin.
I did your both 2 solution.
1. Moving the SelectButton outside the scrollbox is terrible. it requires too much hack, and I were not satisfied with the result.
2. Inheriting the TScrollBox is easier to do, easier to learn, easier to track the changes made to the code.
It is done by interceptor (Same class name as it's ancestor).
And it seem you wouldn't worry about GTK, IMHO ScrollBy would implement by all widgetset; but I don't know for sure.
-
What's next ?
-
What's next ?
Fix regression on gtk2 (freeze) :)
-
I will look at your patch later. Bit busy right now.
Yep, there is a bug somewhere in LCL-GTK. And it is triggered by the layout change.
So now the IDE hangs on gtk2
-
Fix regression on gtk2 (freeze)
And this is why I am so extremely picky, about what I think is correct and what not.
Well in this case the patch was correct. (Never mind the change I did, which I could only do, because the patch was good before).
But it still triggered a bug. The bug is somewhere else (not yet found). But that doesn't matter. I did commit the code that triggered it, and made the IDE freeze.
So I was now forced to look into it.
In the end, I committed a workaround, because the actual bug is in code that I don't know well, and I can only leave it for the attention of someone who does know that code.
The point is, If the code in the patch had contained anything that I would have been doubtful of before the commit, then I would have really been upset about myself. (Because then I would have had to spent time tracking a bug, because I committed something, that I already had thought of as not being good enough).
With the code having been judged as ok by me, the story is different.. I still had to look at it, but well that happens (it happens with my own changes too). At least I took no unnecessary risk.
And at least I could quickly tell the bug was not likely in this code, but someplace else. That is, I could tell that, using "ClientSizeWithoutBar" is meant to work, and meant to work anywhere and anytime, and in any event too
-
@taazz
Slightly OT, but I'm intrigued as to why you choose an OS that annoys you and hinders code development [snip...]
I'm genuinely interested in (possible) advantages of Win8 over its predecessors and non-Windows alternatives.
The most notable plus I can say about windows 8 is the language support that the system has. For example on the laptop I currently have there are 2 user accounts the owner's and mine the owner's is translated in his mother language everything every single aspect of the OS as far as I have checked is translated, while my account is in English, the default installation language and all it took from me was to connect it to the net download and install a language pack.
That one is a big plus from me.
-
What's next ?
Fix regression on gtk2 (freeze) :)
I've looked at the trunk. I know what is going on.
Martin, can we clean up the code from {IFDEF GTK2} now ?
I found another solution that simulate requirement of ClientSizeWithoutBar & ClientSizeWitBar
This will be done by calculate the Scrollbox.Width directly :
(* ==== PLEASE REMOVE IT =========
{$IFDEF LCLGTK2}
MaxBtnPerRow:=((ScrollBox.ClientWidth - 30 - ButtonX) div ComponentPaletteBtnWidth);
{$ELSE}
MaxBtnPerRow:=((ScrollBox.VertScrollBar.ClientSizeWithoutBar - ButtonX) div ComponentPaletteBtnWidth);
// If we need to wrap, make sure we have space for the scrollbar
if MaxBtnPerRow < ButtonTree.Count then
MaxBtnPerRow:=((ScrollBox.VertScrollBar.ClientSizeWithBar - ButtonX) div ComponentPaletteBtnWidth);
{$ENDIF}
======= END REMOVE IT ========== *)
MaxBtnPerRow:=((ScrollBox.Width - ButtonX) div ComponentPaletteBtnWidth); //without scrollbar
if MaxBtnPerRow<1 then MaxBtnPerRow:=1;
// Reduce visible button if there is multiline (scrollbar visible)
Rows := ButtonTree.Count div MaxBtnPerRow;
if MaxBtnPerRow * Rows < ButtonTree.Count then
Inc(Rows);
if Rows > 1 then //multi line?
Dec(MaxBtnPerRow); //reduced.
What do you think ?
-
I can't give patch for now.
since I am also in the middle modifying the unit (vertical-centered button) which is not yet finish.
Update: comment/explanation added
MaxBtnPerRow:=((ScrollBox.Width - ButtonX) div ComponentPaletteBtnWidth); // without scrollbar, first.
if MaxBtnPerRow<1 then MaxBtnPerRow:=1; // avoid division by zero
// Now, reduce visible button if there is multiline (scrollbar visible)
Rows := ButtonTree.Count div MaxBtnPerRow; // its maybe wrong.
if MaxBtnPerRow * Rows < ButtonTree.Count then // correction of integer truncate...
Inc(Rows); // since we don't use Math.CEIL(a/b);
if Rows > 1 then //multi line?
Dec(MaxBtnPerRow); //reduced.
-
if Rows > 1 then //multi line?
Dec(MaxBtnPerRow); //reduced.
Not always correct.
1) In theory on some widget, scrollbar can take more space than one item.
2) if item is 20 pixel width, and scroll bar 10, and total 55, then you need not decrease it at all.
-----------------
The bug in gtk needs to be fixed.
Using ClientSizeWithoutBar is the correct calculation.
So that will be kept.
-
Well, I hope the bug got fixed in few days.
Anyway, I've finished my centered-vertically ComponentPalette buttons.
You can disagree with some part, at least I am satisfied with the (aesthetic) result.
Below is the patch
8-)
-
Guys,
my prior patch is also prepared to handle layout in multiple rows visibility of the component buttons.
Now, how to change the maximum height of IDE form? which unit.pas? which procedure?
I am very curious whether it works as expected.
-
After few hours searching in IDE codes, I found the way to increase IDE mainform's Constraint.MaxHeight.
It is required for showing buttons in Component Palette shown in multiple row.
And it works. :D
I mean my aesthetic expectation/calculation is also perfect in multi-row mode.
My aesthetic philosophy of how component button's position is simple:
* Keep the Arrow/SelectButton in home, it should never go anywhere when scrollbox is scrolled.
* All buttons in component palette should be center-aligned-vertically when in single row.
It is default behavior, since current Lazarus allow only single row.
it is the final-touch of aesthetic aspect: vertical margin distributed equally (margin top = margin bottom).
So, While Lazarus should never show component button in multiple row by design,
The button will always shown centered vertically (not top aligned as in current release)
But, In case Lazarus could show component buttons in multirow (as my experiment), the additional rules is follow:
* All buttons should reflect to Top align in multi-row mode.
This decision is better (in aesthetic perspective) instead of vertically-center.
> when there is too large space available. Too large := ScrollBox.Height >= ButtonHeight * 2
> When there is too small space available. Too small := ScrollBox.Height < ButtonHeight;
Otherwise (if single row or assumed as single row), vertical-center alignment shall be performed.
--------
But, you know we are in early stage of such improvement.
I cant guarantee that my solution is free from bug.
For instance, I found aesthetic bug from my prior patch:
The arrow-button is sometime not in it home when IDE form is resized. It shall always there anytime.
But, it is easy to see the arrow-button again:
click the Vertical-scrollbar to trigger the ScrollBox.ScrollBy event which is the procedure to keep the arrow button to be always visible after scrolled up/down.
-----------
What do you think ?
-
It looks good to me then again the delphi one looked good to me too so....
Can you set the arrow button on the right to bottom aligned as well it seems out of place as it is now looks like a top heavy item balancing on a pin thin leg ready to fall at any time.
-
Can you set the arrow button on the right to bottom aligned as well it seems out of place as it is now looks like a top heavy ...
Sure I can do that. You are talking about the Chevron.
In theory, it would be easier by set Align := alClient
because it stay in a TPanel and this panel Align := alRight
see the attachment. Do you like it?
But it's not the Lazarus in action, the picture below is a mockup made using PaintBrush
-
Can you set the arrow button on the right to bottom aligned ..
Oops, bottom aligned?
IMHO center aligned is better.
But, okay...
Let we compare the above mockup with below one.
-
on your 2 lines height mock up does not make a big difference if centered or bottom although I prefer bottom on this too but here is a mock up from your 2nd screen shot and the real difference between center and bottom. I still think that bottom is better although I don't like it there at all.
But this is your enhancements, thank you for your time, you should choose based on what you like not me.
-
Martin, I think I found the solution including for GTK2 or any other widgetset... if Rows > 1 then //multi line?
Dec(MaxBtnPerRow); //reduced.
Not always correct.
1) In theory on some widget, scrollbar can take more space than one item.
2) if item is 20 pixel width, and scroll bar 10, and total 55, then you need not decrease it at all.
-----------------
The bug in gtk needs to be fixed.
Using ClientSizeWithoutBar is the correct calculation.
So that will be kept.
If the problem is calculation result of scrollbar width, so..
Can we use it to calculate the vertical scrollbar width : ?
LCLIntf.GetSystemMetrics(SM_CXVSCROLL);
LCLIntf.GetSystemMetrics(SM_CXVSCROLL);
as LCLIntf.GetSystemMetrics is widely used in the IDE source code, it seem we can believe it as already implemented by widgetset.
-
LCLIntf.GetSystemMetrics(SM_CXVSCROLL);
That is window only? Not sure, not checked, no need to check, as there is Scrollbar.SIze, that returns the width but that is what is used by already vie ClientWidthWithBar.
-
Can you set the arrow button on the right to bottom aligned ..
Oops, bottom aligned?
IMHO center aligned is better.
...
I still think that bottom is better although I don't like it there at all.
Nice, there is a win-win solution:
* Chevron button should bottom aligned when in multi-row mode. I agree it is better to see in in bottom, it is easier to find it in bottom.
* Chevron button should centered vertically while in single-row mode.
Luckily, we can set it "dinamically": whether to top/bottom alignment according to single/multiple row mode.
Oops, Wait...,
I were liying you. My solution will lies any user's eyes too.
Actually it is always in bottom aligned, but when in single mode, the space between icon to button boundary (top and bottom) are distributed equally.
Meaning the vertical-centered-alignment is only done in our eyes.
The button seem centered vertically. The button it self is still bottom aligned.
see the picture below.
---------
Anyway, if you didn't like to see (the mockup), is because it was too far in bottom IMO.
My correction is to increase the button Width, this way, will move the icon up a bit.
so it seem in the "middle of bottom".
In this case, margin is mater.
But, wait... there is no such margin we used in chevron button case.
So, the margin is measured between the button's Glyph to it's button bounds.
--------
Below is updated patch with ingredients:
* Dynamic alignment of chevron I described above
* Bugfix hidden arrow button when IDE resized and Scrollbox has scrollbar visible.
* Component buttons in the center vertically
Appliying it requires trunk #44848
-
LCLIntf.GetSystemMetrics(SM_CXVSCROLL);
That is window only? Not sure, not checked, no need to check, as there is Scrollbar.SIze, that returns the width but that is what is used by already vie ClientWidthWithBar.
Okay, I am not sure too whether it was cross-widgetset implemented.
As reference, it is used in Lazarus program, main.pas line:1534
AMenuHeight := LCLIntf.GetSystemMetrics(SM_CYMENU);
if AMenuHeight > 0 then
begin
// what we know:
// 1. cmd speedbuttons height = 22
// 2. components palette buttons = 32
// 3. menu height provided by widgetset (varies , depends on theme)
// so we set 22 + 32 + (borders * 2).
MainIDEBar.Constraints.MaxHeight := AMenuHeight +
22 {cmd speedbtns} + 32 {component buttons} * 3 {multirow} +
LCLIntf.GetSystemMetrics(SM_CYSIZEFRAME) +
(LCLIntf.GetSystemMetrics(SM_CYBORDER) * 2) {borders};
end else
MainIDEBar.Constraints.MaxHeight:=85;
The red text is my own modification to make Lazarus able to show multiple-row of COmponentPalette buttons.
-
Well It seem I failed to make text color as red inside the "CODE" block.
I refer to this text:
* 3 {multirow}
-
Martin, below patch is for you.
I've clean up another proposal solution.
I hope you like it :D
Regards,
x2nie
-
Ok, this thread is now so long, that it becomes hard to keep track of any of the patches you submitted.
Also I do not know if any other developers who might help with it are aware of this (afaik not all developers are on the forum).
If you consider any of the not yet applied patches to be ready, then you should submit them on our bug tracker.
-
Agree, it was too long as from expected. Perhaps we need to close this topic soon. Then move it on Bugtracker or Mailist. Yesterday I've subscribe in both mailist + bugtrack.
I think I am ready now to go there.
However I am happy discussing in forum way, however. Due my irritation is not because it is a bug, this discussion was in cosmetic level.
I love to say it were suggestions, not a bug found. Therefor there is nothing such bugfix in fact.
My apologize for a provoke title.
[size=78%] [/size]
Long live Lazarus !!!
Thanks you very much.
-
FInally it is moved here: http://mantis.freepascal.org/view.php?id=26097