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
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
Abdelrazak Younes wrote:
> Well InsetInfo::MENU_INFO _is_ available, it is just that it is not used
> (yet).
I see. Great.
Jürgen
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:
> > 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
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
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
23 matches
Mail list logo
