On Tue, Jun 3, 2008 at 9:55 AM, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
>> I do not see any trouble in this approach.
>
> Except that it makes maintenance a bit more difficult, if every new function
> will have to be added to 3 menu files. Even with our two files now, new
> f
Bo Peng wrote:
> I do not see any trouble in this approach.
Except that it makes maintenance a bit more difficult, if every new function
will have to be added to 3 menu files. Even with our two files now, new
features have often been forgotten to be added to classic.ui.
So it only works if thes
Bo Peng wrote:
1) Platform-dependent
2) A compromise (=mix) between different HIG
3) Stick to one platform HIG, give a sh.. about the others
4) Do nothing.
Each has pros and cons.
I would be for 1) if somebody is willing to create the necessary
infrastructure in terms of documentation, an for 2
> 1) Platform-dependent
> 2) A compromise (=mix) between different HIG
> 3) Stick to one platform HIG, give a sh.. about the others
> 4) Do nothing.
>
> Each has pros and cons.
>
> I would be for 1) if somebody is willing to create the necessary
> infrastructure in terms of documentation, an for 2)
Konrad Hofbauer wrote:
1) Platform-dependent
2) A compromise (=mix) between different HIG
3) Stick to one platform HIG, give a sh.. about the others
4) Do nothing.
...
>
I do not think 2) is users-list-wise such a big issue as long as we keep
the names of the menu-entries the same (e.g. "Reco
Jürgen Spitzmüller wrote:
I don't think a mix of different guidelines is what we want. In such a case,
rather change it to the Mac HIG for the Mac people, and leave it for Linux as
is.
I have a rather strong believe that we have four exclusive options and
should decide on one and strictly fol
Bennett Helm wrote:
> Seriously, if there's no agreement on changing the status quo here, the
> status quo wins.
And vice versa, of course. I'm just stating my personal options.
Jürgen
On Tue, Jun 3, 2008 at 8:20 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]>
wrote:
> Bennett Helm wrote:
> > Naturally all of these suggestions won't be
> > acceptable precisely because, as you say, Linux and Windows users have
> > different guidelines. But I think it's worth looking at it and thinking
Bennett Helm wrote:
* Shouldn't bundling/compression menu items go with save menu items?
There's actually a bug report about this somewhere.
rh
Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
I fully agree to that. And it is the same with Shell vs. GNOME vs. KDE
vs. Windows vs. Mac vs. ... And I believe that in a menu structure
discussion most likes and dis-likes would be because what one is used to
on "his" platform.
Agreed.
On Tue, Jun 3, 2008 at 5:08 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> Konrad Hofbauer wrote:
>
>> Another careful inquiry on people's opinion (and to find out how much work
>> would be involved).
>>
>> Jürgen Spitzmüller wrote:
>>
>>> Also, we should not follow our intuition alone, but so
Bennett Helm wrote:
> Naturally all of these suggestions won't be
> acceptable precisely because, as you say, Linux and Windows users have
> different guidelines. But I think it's worth looking at it and thinking
> about changes nonetheless.
I don't think a mix of different guidelines is what we w
On Tue, Jun 3, 2008 at 2:35 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]>
wrote:
> rgheck wrote:
> > There are no fundamental code changes here, so it's not too late in
> > principle.
>
> Note, however, that all documentation needed to be rewritten in such a case
> (as long as we do not have a Menu I
Konrad Hofbauer <[EMAIL PROTECTED]> writes:
[...]
>
> So my big question is:
>
> *** Should the menu stucture be platform-specific ? ***
>
> *** PROS ***
> + Consistency accross different applications.
> + Things are where the user expects them.
> + LyX can better conform to the platform HIG.
>
Abdelrazak Younes wrote:
> Well InsetInfo::MENU_INFO _is_ available, it is just that it is not used
> (yet).
I see. Great.
Jürgen
Konrad Hofbauer wrote:
> I fully agree to that. And it is the same with Shell vs. GNOME vs. KDE
> vs. Windows vs. Mac vs. ... And I believe that in a menu structure
> discussion most likes and dis-likes would be because what one is used to
> on "his" platform.
Agreed.
> So my big question is:
>
>
Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
Note, however, that all documentation needed to be rewritten in such a
case
True.
(as long as we do not have a Menu Inset Info).
I do not understand what this means/involves.
An inset that can automatically display
Konrad Hofbauer wrote:
- Non-uniform appearance of LyX accross platforms
We could make this user-configurable in the preferences (default to
platform), for those people that switch between platforms and want the
same menus.
Other points to add? Opinions?
Personally, I do not have a stron
Konrad Hofbauer wrote:
> > Note, however, that all documentation needed to be rewritten in such a
> > case
>
> True.
>
> > (as long as we do not have a Menu Inset Info).
>
> I do not understand what this means/involves.
An inset that can automatically display the correct patch depending on the
us
Konrad Hofbauer wrote:
Another careful inquiry on people's opinion (and to find out how much
work would be involved).
Jürgen Spitzmüller wrote:
Also, we should not follow our intuition alone, but some Human
Interface Guideline. The current menu structure follows the KDE HIG,
which is probably
Jürgen Spitzmüller wrote:
Note, however, that all documentation needed to be rewritten in such a case
True.
(as long as we do not have a Menu Inset Info).
I do not understand what this means/involves.
Also, we should not follow our intuition alone, but some Human Interface
Guideline. The
Another careful inquiry on people's opinion (and to find out how much
work would be involved).
Jürgen Spitzmüller wrote:
Also, we should not follow our intuition alone, but some Human Interface
Guideline. The current menu structure follows the KDE HIG, which is probably
why first and foremost
Bennett Helm wrote:
So ... have at it.
Is that an OmniOutliner export? If so, would you post the oo-file?
/Konrad
rgheck wrote:
> There are no fundamental code changes here, so it's not too late in
> principle.
Note, however, that all documentation needed to be rewritten in such a case
(as long as we do not have a Menu Inset Info).
Also, we should not follow our intuition alone, but some Human Interface
Gu
On Mon, Jun 2, 2008 at 5:39 PM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:
> Dear all,
>
> I just tested 1.6.0beta2, and since a new major version is on its ways, I'd
> like to make a careful inquiry about how you would feel about a fundamental
> GUI _menu_ structure overhaul?
>
> In my point of v
Konrad Hofbauer wrote:
> In my point of view there are a view inconsistencies, and even after
> extended use (and cross-platform experience) some entries are still very
> not intuitive to me.
this is right also to me, but the problem is that when i start thinking about
changes i come to quite co
Abdelrazak Younes wrote:
> Implementation is quite easy, you just have to play with
> lib/ui/stdmenu.ui
Hey, just tried, even I can do that. :-)
/Konrad
> I like your proposal personally but, as you correctly guessed, this is a
> highly sensitive subject :-)
I also like your proposal because I had a hard time to differentiate
File and Document when I translate the UI to Chinese. Can anyone name
a popular application with both File and Document men
Konrad Hofbauer wrote:
Dear all,
I just tested 1.6.0beta2, and since a new major version is on its
ways, I'd like to make a careful inquiry about how you would feel
about a fundamental GUI _menu_ structure overhaul?
Well, I guess it makes me feel kind of giddy. ;-)
In my point of view ther
Konrad Hofbauer wrote:
Dear all,
I just tested 1.6.0beta2, and since a new major version is on its
ways, I'd like to make a careful inquiry about how you would feel
about a fundamental GUI _menu_ structure overhaul?
In my point of view there are a view inconsistencies, and even after
extend
Dear all,
I just tested 1.6.0beta2, and since a new major version is on its ways,
I'd like to make a careful inquiry about how you would feel about a
fundamental GUI _menu_ structure overhaul?
In my point of view there are a view inconsistencies, and even after
extended use (and cross-platfo
31 matches
Mail list logo
