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 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
>
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 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
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
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
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
--
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
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
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
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
43 matches
Mail list logo