On Sun, Jan 17, 2016 at 8:40 PM, Howard wrote:
> On 17/01/2016 13:00, Juha Manninen wrote:
>> Howard, for curiosity, your patch has: LCLVersion = '1.6.0.2' The menu
>> editor is developed in trunk 1.7. Are you using a fixex_1_6 version for
>> editing? Juha
>
> Yes, the code I
On Thu, 21 Jan 2016 13:21:57 +
Howard Page-Clark wrote:
>[...]
> I don't know anything about the translation process, or at what stage in
> the IDE initialization captions are replaced with translated
> resourcestrings.
> Is there a standard notification, or other means
On 20/01/16 17:30, Péter Gábor wrote:
Width of the designed menu must be calculated using the length of
captions including the lenght of actual translation of "Add menuitem"...
Otherwise if the menu captions are too short the command's caption will
not fit.
See the attached screenshot.
Yes, in
On 21/01/16 13:29, Mattias Gaertner wrote:
On Thu, 21 Jan 2016 13:21:57 +
Howard Page-Clark wrote:
[...]
I don't know anything about the translation process, or at what stage in
the IDE initialization captions are replaced with translated
resourcestrings.
Is there a
Width of the designed menu must be calculated using the length of
captions including the lenght of actual translation of "Add menuitem"...
Otherwise if the menu captions are too short the command's caption will
not fit.
See the attached screenshot.
--
Péter Gábor
p...@freemail.hu
--
20.01.2016 17:15, Howard Page-Clark пишет:
> On 17/01/16 23:22, Maxim Ganetsky wrote:
>> 16.01.2016 1:19, Howard пишет:
>>> I have submitted a patch (29411) which I hope addresses these issues,
>>> except for the issue:
>>> 'String "composing" is still present ... in main menu creation form in
On 17/01/16 23:22, Maxim Ganetsky wrote:
16.01.2016 1:19, Howard пишет:
I have submitted a patch (29411) which I hope addresses these issues,
except for the issue:
'String "composing" is still present ... in main menu creation form in
"add menu item" fields captions'
I am not clear about which
On 1/18/16, Lukasz Sokol wrote:
> I'm with Howard here (and Matthias). It should be a default No if a change
> can not be reversed by just Ctrl-Z or Undo.
Obey widgetset behaviour.
> if a change
> can not be reversed by just Ctrl-Z or Undo.
Implement Undo for the
On 18/01/16 10:36, Ondrej Pokorny wrote:
> On 18.01.2016 10:42, Lukasz Sokol wrote:
>> Then maybe make the 'No' answer default here?
>
> No. If I hit delete, I want to delete the button. The prompt is OK
> there but the default action should always be what you want to do ->
> "yes". Don't assume
On 18.01.2016 14:03, Lukasz Sokol wrote:
Btw. Howard had the "No" button default but I changed it.
I'm with Howard here (and Matthias
As far as I understood Mattias' email, he did not say the dialog should
default to "Yes".
Btw. I checked when deleting files in the default file manager
On Mon, 18 Jan 2016 11:36:57 +0100
Ondrej Pokorny wrote:
> On 18.01.2016 10:42, Lukasz Sokol wrote:
> > Then maybe make the 'No' answer default here?
>
> No. If I hit delete, I want to delete the button. The prompt is OK there
> but the default action should always be what
On 18.01.2016 10:42, Lukasz Sokol wrote:
Then maybe make the 'No' answer default here?
No. If I hit delete, I want to delete the button. The prompt is OK there
but the default action should always be what you want to do -> "yes".
Don't assume that people are dumb :)
Btw. Howard had the "No"
On 16/01/16 23:11, Howard wrote:
[...]
> In this particular instance of deleting a submenu (not just a single
> item) my motivation was not to make it overly complicated (though I
> appreciate it may seem so). It is quite possible a user may have
> spent 10 minutes designing a submenu with half a
On 18/01/16 15:20, Ondrej Pokorny wrote:
> On 18.01.2016 14:03, Lukasz Sokol wrote:
>>> Btw. Howard had the "No" button default but I changed it.
>>>
>> I'm with Howard here (and Matthias
>
> As far as I understood Mattias' email, he did not say the dialog
> should default to "Yes".
Heh you're
On 18.01.2016 15:51, Bart wrote:
Implement Undo for the menu-desgner will be on the wish list then.
+1. Changing properties in OI and deleting components already are
supported by the Undo function. The menu editor should support it as well.
Ondrej
--
On 17/01/2016 12:33, Péter Gábor wrote:
I found some Format calls that seems to be unneded: the first parameter
for them contains only formatting symbols and the second an array of
resourcestrings.
If no one else is currently working on the resourcestrings issue I will
try to finish my patch
I think we can use one resourcestring ('')
instead of three:
'';
'';
'';
Yes or No?
2016-01-17 17:33 keltezéssel, Péter Gábor írta:
>
> 2016-01-17 14:00 keltezéssel, Juha Manninen írta:
>> There is a patch from Howard:
>> http://bugs.freepascal.org/view.php?id=29411
>
> I did not notice it
On 17/01/2016 13:00, Juha Manninen wrote:
...
Howard, for curiosity, your patch has: LCLVersion = '1.6.0.2' The menu
editor is developed in trunk 1.7. Are you using a fixex_1_6 version
for editing? Juha
Yes, the code I worked on was the latest trunk (well perhaps it was from
the day before).
On 17/01/2016 18:40, Péter Gábor wrote:
I think we can use one resourcestring ('')
instead of three:
'';
'';
'';
Yes or No?
Yes, I agree with you.
Howard
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
16.01.2016 1:19, Howard пишет:
I have submitted a patch (29411) which I hope addresses these issues,
except for the issue:
'String "composing" is still present ... in main menu creation form in
"add menu item" fields captions'
I am not clear about which string(s) you are identifying here. Can
On 17.01.2016 0:11, Howard wrote:
In this particular instance of deleting a submenu (not just a single
item) my motivation was not to make it overly complicated (though I
appreciate it may seem so).
It is quite possible a user may have spent 10 minutes designing a
submenu with half a dozen
On Sun, Jan 17, 2016 at 1:11 AM, Howard wrote:
> You'll realise I'm on a learning curve. This is my first significant code
> contribution to an open source project. I actually never thought I had the
> skill to offer a new menueditor. It was a forum comment by the late
>
I found some Format calls that seems to be unneded: the first parameter
for them contains only formatting symbols and the second an array of
resourcestrings.
If no one else is currently working on the resourcestrings issue I will
try to finish my patch and post it on mantis...
This is more
On Sun, Jan 17, 2016 at 2:33 PM, Péter Gábor wrote:
> If no one else is currently working on the resourcestrings issue I will
> try to finish my patch and post it on mantis...
> This is more simpler than writing a lot of letter about what and how to
> fix to be translation
2016-01-17 14:00 keltezéssel, Juha Manninen írta:
> There is a patch from Howard:
> http://bugs.freepascal.org/view.php?id=29411
I did not notice it yet.
> Péter, can you please look at it and maybe attach your improved patch
> to the same report.
Okay, now I'm working on it...
--
Péter
On 23/12/2015 19:19 μμ, Juha Manninen wrote:
On Wed, Dec 23, 2015 at 9:26 AM, taazz wrote:
stop f...ing with my system
Actually we are f...ing with Lazarus trunk, not with your system.
If you want a stable Lazarus, you should use the fixes_1_6 branch instead.
It is starting to
On 16.01.2016 16:55, taazz wrote:
Actually we are f...ing with Lazarus trunk, not with your system.
If you want a stable Lazarus, you should use the fixes_1_6 branch
instead.
It is starting to look very good!
Using fsstayontop you are f...ing with my system! never mind I'll
extend the
On 23/12/2015 12:21 μμ, Ondrej Pokorny wrote:
On 23.12.2015 08:54, taazz wrote:
I know that Delphi behaves the same but then we need some FormStyle
that makes the window stay only on top of its application windows
and not system-wide.
No it does not, delphi's 2007 menu designer never stays
On 15.01.2016 23:30, Howard wrote:
Sorry, my apologies - I missed that you didn't try it.
Yes working fine for me (Windows 7 32bit and Linux 64 bit).
I'm relieved that such a simple change has had such a good effect, and
that no further tinkering with TShadowMenu size and positioning code
On 16/01/2016 21:08, Ondrej Pokorny wrote:
On 15.01.2016 23:30, Howard wrote:
Sorry, my apologies - I missed that you didn't try it.
Yes working fine for me (Windows 7 32bit and Linux 64 bit).
I'm relieved that such a simple change has had such a good effect,
and that no further tinkering
On 16/01/2016 18:39 μμ, Ondrej Pokorny wrote:
On 16.01.2016 16:55, taazz wrote:
Actually we are f...ing with Lazarus trunk, not with your system.
If you want a stable Lazarus, you should use the fixes_1_6 branch
instead.
It is starting to look very good!
Using fsstayontop you are
2016-01-15 00:27 keltezéssel, Maxim Ganetsky írta:
> String "composing" is still present e. g. in "Insert from template"
> dialog ("Choose template to ..." groupbox caption) and in main menu
> creation form in "add menu item" fields captions.
>
> Also
On 11.01.2016 21:36, Howard wrote:
On 11/01/2016 16:07, Anthony Walter wrote:
Very nice. I like the new design.
Side note: Who wrote that FScroller for the new menu editor? It acts
very erratic for me on Gtk2. I don't know about on other widget sets.
See issue 29369. Why not use TScrollBox
On 15.01.2016 11:32, Ondrej Pokorny wrote:
What were your problems? In r51298 I removed all the Scroller code and
simply used TScrollBox for TShadowMenu and it works without any
problems - much better than your Scroller experiment. I tested win32
and Linux+Gtk2.
Forgot to say, please test :)
On 15.01.2016 11:32, Ondrej Pokorny wrote:
I did not try making TShadowMenu a TScrollingWinControl descendant.
Perhaps that would be a better option. What would others advise?
What were your problems? In r51298 I removed all the Scroller code and
simply used TScrollBox for TShadowMenu and it
2016-01-15 08:50 keltezéssel, Péter Gábor írta:
>
>
> 2016-01-15 00:27 keltezéssel, Maxim Ganetsky írta:
>> String "composing" is still present e. g. in "Insert from template"
>> dialog ("Choose template to ..." groupbox caption) and in main menu
>> creation form in "add menu item" fields
On 14/01/2016 23:27, Maxim Ganetsky wrote:
String "composing" is still present e. g. in "Insert from template"
dialog ("Choose template to ..." groupbox caption) and in main menu
creation form in "add menu item" fields captions.
Also lismenueditororclickheadertosortbythatcolumn string looks
On 15/01/2016 11:04, Ondrej Pokorny wrote:
On 15.01.2016 11:32, Ondrej Pokorny wrote:
I did not try making TShadowMenu a TScrollingWinControl descendant.
Perhaps that would be a better option. What would others advise?
What were your problems? In r51298 I removed all the Scroller code
and
12.01.2016 22:17, Howard пишет:
On 12/01/2016 14:37, Péter Gábor wrote:
2016-01-12 15:26 keltezéssel, Howard írta:
OK, point taken. I will amend the offending resourcestrings in a patch.
I'm not a linguist nor a translator, so did not appreciate that this
would cause difficulty.
My motive was
On 11/01/2016 21:51, Anthony Walter wrote:
Howard, good job on the new menu designer. It's working very nicely
right now. I'll take a look at modifying TShadowMenu to be a scrolling
control without the need for a TScrollBox.
Thanks. Yes, Ondrej's introduction of TSiblingFake and TFirstFake
On 12.01.2016 9:39, Howard wrote:
Yes, Ondrej's introduction of TSiblingFake and TFirstFake are a neat
improvement.
Thanks! You did a nice job with the menu designer!
I would ask you to omit the with statement, though. IIRC there are even
nested with statements in the code.
Withs can
On 12/01/2016 13:44, Péter Gábor wrote:
Please use complete sentences as much as possible and avoid storing > of partial sentences in resourcestrings. I mean don't compose >
complete sentences in run/compile time from words or partial >
sentences. Such resourcestrings makes localization harder
2015-12-26 20:37 keltezéssel, Howard Page-Clark írta:
> I was waiting for more feedback about the design/functionality, and for
> responses to settle into some sort of consensus about what needs to be
> changed/improved/removed.
> The resourcestrings, for instance, need the attention Peter
>
On 12/01/2016 14:37, Péter Gábor wrote:
2016-01-12 15:26 keltezéssel, Howard írta:
OK, point taken. I will amend the offending resourcestrings in a patch.
I'm not a linguist nor a translator, so did not appreciate that this
would cause difficulty.
My motive was simply to reduce the overall
Hello i testet SVN Revision 51256 of the Menu designer and it looks
really cool.
But i miss the Feature
"If you doubleclick on the Menu Entry the IDE Jumps to the corresponding
OnCLick Event"
Which worked in the old version e.g. 50469
Could you please reactivate this ?
Corpsman
--
2016-01-12 15:26 keltezéssel, Howard írta:
> OK, point taken. I will amend the offending resourcestrings in a patch.
> I'm not a linguist nor a translator, so did not appreciate that this
> would cause difficulty.
> My motive was simply to reduce the overall number of resourcestrings
> required
Howard, good job on the new menu designer. It's working very nicely right
now. I'll take a look at modifying TShadowMenu to be a scrolling control
without the need for a TScrollBox.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 11.01.2016 10:09, Anthony Walter wrote:
No matter where I click it always shows the same pattern: ugly blue
check board below, ugly aliased triangles to the right.
Can you please define "ugly" in an objective way?
I can say the same about your approach: "/No matter where I click it
always
On 11.01.2016 4:33, Dmitry Boyarintsev wrote:
The bottom one. It's more "calm". Doesn't look like a circus.
I prefer the old one (top) :) The arrows/squares are very neat and show
what you are going to do.
If you think it looks like a circus, what about using a less agressive
colour for
On 11.01.2016 9:35, Ondrej Pokorny wrote:
I prefer the old one (top) :) The arrows/squares are very neat and
show what you are going to do.
Arrows: new submenu item.
Squares: new sibling menu item.
Very neat, IMO. Not to be removed, please :)
Ondrej
--
In my opinion the top one is kind of terrible. Just look at this video:
http://cache.getlazarus.org/videos/menu-arrows.mp4
No matter where I click it always shows the same pattern: ugly blue check
board below, ugly aliased triangles to the right.
I can tell the item is going to be inserted
The top one.
I find there is room for beauty (ugly?) and personality in programming.
I find straight forward utilitarian to be ugly. I like things to be
interesting.
Any way to make the pattern settable? Win-Win!
On 01/11/2016 10:34 AM, Anthony Walter wrote:
> The point is, on a TPopupMenu if
On 2016-01-11 03:33, Dmitry Boyarintsev wrote:
> The bottom one. It's more "calm". Doesn't look like a circus.
+1
Regards,
- Graeme -
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
The point is, on a TPopupMenu if the pattern to the right is always alias
arrows, and the pattern below is always check board, then it's entirely
superfluous, nonessential, redundant, and unneeded.
--
___
Lazarus mailing list
On 2016-01-11 09:21, Ondrej Pokorny wrote:
> IMO, it is very clear, again:
> - Arrows: new submenu item.
> - Squares: new sibling menu item.
As a programmer the bottom image is equally clear to me. I simply find
the bottom one more pleasing to the eye - less distracting.
If the arrows and
On 11/01/2016 16:07, Anthony Walter wrote:
Very nice. I like the new design.
Side note: Who wrote that FScroller for the new menu editor? It acts
very erratic for me on Gtk2. I don't know about on other widget sets.
See issue 29369. Why not use TScrollBox or make TShadowMenu a
On my system suddenly all is well with the new menu editor. Nice work :)
The docked form designer still has the issue where it's not being
realigned/repainted when a TMainMenu is placed on it. Issue 29370.
--
___
Lazarus mailing list
On 11/01/2016 12:35, Ondrej Pokorny wrote:
On 11.01.2016 13:31, Howard wrote:
The latest trunk accepts a patch which adopts Bart's suggestion of
identifying the purpose of the dummy menuitem by displaying a
self-descriptive text. The background is no longer patterned. Of
course this can be
On 11.01.2016 14:20, Bart wrote:
In the image below, which style do you prefer. The top or bottom?
The bottom one.
Looks like I have been outvoted :) No problem.
On 11.01.2016 10:09, Anthony Walter wrote:
ugly aliased triangles
On 11.01.2016 11:25, Graeme Geldenhuys wrote:
If the arrows
On 1/11/16, Anthony Walter wrote:
> In the image below, which style do you prefer. The top or bottom?
Suggestion: can you put the buttons in a grid like container?
With at least vertical lines between the different groups.
Bart
--
On Mon, Jan 11, 2016 at 3:38 PM, Howard wrote:
> It is the second patch submitted on issue 29205
Oops, I failed to notice it. Should it be applied?
I am happy if the issue is assigned to somebody else. Bart? Ondrej?
I have some other issues to look at.
Juha
--
On 11.01.2016 14:51, Juha Manninen wrote:
Oops, I failed to notice it. Should it be applied?
I'll apply it manually. The patch won't apply because I fixed some
issues recently.
Ondrej
--
___
Lazarus mailing list
On Mon, Jan 11, 2016 at 4:18 PM, Ondrej Pokorny wrote:
> I'll apply it manually. The patch won't apply because I fixed some issues
> recently.
Assigned the issue to you. Thanks. :)
Juha
--
___
Lazarus mailing list
On 11.01.2016 13:31, Howard wrote:
The latest trunk accepts a patch which adopts Bart's suggestion of
identifying the purpose of the dummy menuitem by displaying a
self-descriptive text. The background is no longer patterned. Of
course this can be further changed.
Where is the patch?
Ondrej
On 1/11/16, Anthony Walter wrote:
> In the image below, which style do you prefer. The top or bottom?
The bottom one.
Please add a text to it so one knows what it does.
Keep up the good work !!!
Bart
--
___
Lazarus mailing list
On 11/01/2016 09:34, Anthony Walter wrote:
The point is, on a TPopupMenu if the pattern to the right is always
alias arrows, and the pattern below is always check board, then it's
entirely superfluous, nonessential, redundant, and unneeded.
The latest trunk accepts a patch which adopts Bart's
dblClick does not actually show assignde Code?!!
just svn-updated lazarus:
Lazarus 1.7 r1.5 FPC 2.6.4 x86_64-linux-gtk 2
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Very nice. I like the new design.
Side note: Who wrote that FScroller for the new menu editor? It acts very
erratic for me on Gtk2. I don't know about on other widget sets. See
issue 29369. Why not use TScrollBox or make TShadowMenu a
TScrollingWinControl?
--
On 11.01.2016 14:38, Howard wrote:
It is the second patch submitted on issue 29205
Applied. IMO the discussion about the pattern is now solved :)
Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Am 11.01.2016 um 18:26 schrieb John Landmesser:
dblClick does not actually show assignde Code?!!
just svn-updated lazarus:
Lazarus 1.7 r1.5 FPC 2.6.4 x86_64-linux-gtk 2
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 11.01.2016 17:07, Anthony Walter wrote:
Side note: Who wrote that FScroller for the new menu editor? It acts
very erratic for me on Gtk2. I don't know about on other widget sets.
See issue 29369.
You can easily check by yourself in the SVN history. I don't know.
Why not use TScrollBox
In the image below, which style do you prefer. The top or bottom?
http://cache.getlazarus.org/images/menu-patterns.gif
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
The bottom one. It's more "calm". Doesn't look like a circus.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 12/22/15, Juha Manninen wrote:
> Hello
>
> I committed a new Menu Designer by Howard Page-Clark in r50992.
> See:
> http://bugs.freepascal.org/view.php?id=29205
Can we implement it so that adding a sumnenu to a Separator (a
menuItem with '-' as caption) will
On 04/01/2016 14:24, Bart wrote:
On 12/22/15, Juha Manninen wrote:
Hello
I committed a new Menu Designer by Howard Page-Clark in r50992.
See:
http://bugs.freepascal.org/view.php?id=29205
Can we implement it so that adding a sumnenu to a Separator (a
menuItem
On 1/4/16, Bart wrote:
>> In the new menu editor adding a submenu to a separator is already
>> disallowed (popup menu option/toolbutton is disabled if a separator is
>> highlighted). Do you not find this?
>
> Shamefully admits: I did not check that.
Checked it. Fine.
Can
On 1/4/16, Howard Page-Clark wrote:
> In the new menu editor adding a submenu to a separator is already
> disallowed (popup menu option/toolbutton is disabled if a separator is
> highlighted). Do you not find this?
Shamefully admits: I did not check that.
> However, the
On 26/12/2015 23:27, Juha Manninen wrote:
Howard, as the author you also have voting power over the GUI.
Besides GUI design is difficult, there is never a "right" solution
that everybody would agree upon.
Yes, dictatorship is far more efficient than democracy.
Yet I feel some things should be
On Sun, Dec 27, 2015 at 1:34 PM, Howard Page-Clark wrote:
> Yes, dictatorship is far more efficient than democracy.
True, but this is neither dictatorship nor democracy. This is more
like meritocracy. :)
>> There are other usability issues, too.
> Namely...?
Top level
On 22.12.2015 23:42, Anthony Walter wrote:
Stay on top is needed because the a menu designer is typically a
separate non docking window (a dialog). For all users menu editing
invariably consists of:
1. Creating a menu (or sub menu) item using the menu editor dialog
2. Then editing the menu
On 27/12/2015 13:25, Ondrej Pokorny wrote:
On 27.12.2015 14:21, Juha Manninen wrote:
On Sun, Dec 27, 2015 at 2:46 PM, Ondrej Pokorny
wrote:
>Highlighting works fine on Windows. It doesn't work on Linux. I haven't
>checked OSX.
Strange. I have tested with GTK2 and QT on
On 27.12.2015 13:10, Juha Manninen wrote:
Top level menuitems in a MainMenu can be selected but there is no
indication about it. Other items get a blue rectancle.
Highlighting works fine on Windows. It doesn't work on Linux. I haven't
checked OSX.
Ondrej
--
On Sun, Dec 27, 2015 at 2:46 PM, Ondrej Pokorny wrote:
> Highlighting works fine on Windows. It doesn't work on Linux. I haven't
> checked OSX.
Strange. I have tested with GTK2 and QT on Linux and the Windows
version using Wine. They all behave identically in this respect.
On 27.12.2015 14:21, Juha Manninen wrote:
On Sun, Dec 27, 2015 at 2:46 PM, Ondrej Pokorny wrote:
>Highlighting works fine on Windows. It doesn't work on Linux. I haven't
>checked OSX.
Strange. I have tested with GTK2 and QT on Linux and the Windows
version using Wine. They
On Sat, Dec 26, 2015 at 1:09 PM, Péter Gábor wrote:
> Some examples of resourcestrings that can/must be merged
> ...
Yes, I didn't even notice that.
> Also a question: can this (new) menu designer implemented as a
> separate/installable package to allow the usage of old one?
On 26/12/2015 19:06, Juha Manninen wrote:
On Sat, Dec 26, 2015 at 1:09 PM, Péter Gábor wrote:
Some examples of resourcestrings that can/must be merged
No, my idea was to replace the old menu designer with a new one.
Something is wrong with the design of the old one.
Hi!
2015-12-23 12:31 keltezéssel, Maxim Ganetsky írta:
> BTW, from localizer POV 150-180 extra resource strings that were added
> with this patch (which is a VERY bug number) point to likely
> functionality duplication. :)
Some examples of resourcestrings that can/must be merged
Editing %s.%s -
Howard, as the author you also have voting power over the GUI.
Besides GUI design is difficult, there is never a "right" solution
that everybody would agree upon.
Yet I feel some things should be changed. All settings that duplicate
OI properties should either be moved to a bottom section of a
On 23.12.2015 22:46, Dmitry Boyarintsev wrote:
Did you try restoring thumbnail mode for Alt-tab?
It works well in thumbnail mode. The fsStayOnTop-window gets correctly
hidden behind the new external (Thunderbird, whatever) window when
switched to it with Alt+Tab.
But this is not a
On 23.12.2015 19:12, Ondrej Pokorny wrote:
I hope Zeljko can find an easy way to do it. It would be a pity if we
couldn't use PopupParent/PopupMode because it is not supported on
Qt/Gtk2 :(
Zeljko fixed support of PopupParent/PopupMode in Qt and me in Gtk2 in
r51022, r51023.
Please test. It
On 23.12.2015 18:54, Dmitry Boyarintsev wrote:
To sum things up: using fsStayOnTop in the new menu designer is not bad.
If fsStayOnTop worked as it is documented, I would be all for it.
But
1.) it has issues on Windows.
2.) it completely fails on Linux/KDE.
So, no, it is bad :(
Ondrej
--
On 23.12.2015 08:54, taazz wrote:
I know that Delphi behaves the same but then we need some FormStyle
that makes the window stay only on top of its application windows and
not system-wide.
No it does not, delphi's 2007 menu designer never stays on top outside
the application it self and
23.12.2015 02:39, Juha Manninen пишет:
> On Wed, Dec 23, 2015 at 12:42 AM, Anthony Walter wrote:
>> As such, in the case of editor menus, it makes total sense to keep the menu
>> editor on top of other IDE windows until the time when the user closes the
>> menu editor (clicks
On 23.12.2015 08:26, taazz wrote:
On 23/12/2015 00:42 πμ, Anthony Walter wrote:
Ondrej,
The old menu designer was stay on top as well.
Why would I need to see the menu designer when I change application to
anything other than lazarus? The old behavior is why I still design my
menus in
On Wed, Dec 23, 2015 at 2:26 AM, Ondrej Pokorny wrote:
> What I don't like on fsStayOnTop is the fact that fsStayOnTop-Window wants
> to stay on top of all windows - also those from other applications. This is
> IMO a seriously bad UI design. I know that Delphi behaves the
On Wed, Dec 23, 2015 at 9:26 AM, taazz wrote:
> stop f...ing with my system
Actually we are f...ing with Lazarus trunk, not with your system.
If you want a stable Lazarus, you should use the fixes_1_6 branch instead.
It is starting to look very good!
Juha
--
On 23.12.2015 19:18, Dmitry Boyarintsev wrote:
On Wed, Dec 23, 2015 at 12:11 PM, Ondrej Pokorny > wrote:
No, this is not true. It does bother my email client such as any
other fsStayOnTop window, see attachment - from the Win10 theme
you
On Wed, Dec 23, 2015 at 12:11 PM, Ondrej Pokorny wrote:
> No, this is not true. It does bother my email client such as any other
> fsStayOnTop window, see attachment - from the Win10 theme you can recognize
> that the email client window is focused and active and is still
On 23.12.2015 17:26, Dmitry Boyarintsev wrote:
fsStayOnTop - stay on top of all windows within the application
fsSystemStayOnTop - stay on top of all windows within system.
For the sake of backwards compatibility the other way round would
be more appropriate, IMO:
fsAppStayOnTop - stay on
On 23.12.2015 17:30, Dmitry Boyarintsev wrote:
On Wed, Dec 23, 2015 at 11:26 AM, Dmitry Boyarintsev
> wrote:
fsStayOnTop - stay on top of all windows within the application
fsSystemStayOnTop - stay on top of all windows
1 - 100 of 127 matches
Mail list logo