straw-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Straw-devel] updated alternate ui layout


From: Juri Pakaste
Subject: Re: [Straw-devel] updated alternate ui layout
Date: Thu, 15 Jul 2004 11:42:29 +0300

On Thu, 2004-07-15 at 10:18 +0200, Lucas Nussbaum wrote:
> I don't like the idea of having this kind of options in Straw. This
> makes debugging much harder, since you have to know exactly what
> options are being used by the reporter. 

Yeah, I don't like adding too many twiddly options myself.

> We should avoid the tentation of listening to each and every user
> suggestion. I've seen cases in another project where somebody asked for
> something and wouldn't even use it.

Sure. I think I'm mostly pretty good at shooting down suggestions. Best
limiter on these is the very limited developer resources. Development
has been fast lately due to me being on a vacation and Finland having
thus far lousy weather this summer, but normally when I'm able to put in
just a few hours a week, it's easy to stay focused on stuff that's
important :-)

> In the specific case of straw, I don't think we should support another
> rendering engine. gtkhtml2 just suits our needs. 

I'm not quite sure what you mean here: I don't think we should support
multiple rendering engines either. However, I wouldn't mind dumping
gtkhtml2, once Gecko/Gtk+ integration is good enough. It's not there yet
and I have no idea if it's progressing.

Besides, the choice might be taken out of our hands. If yelp switches
from gtkhtml2 to Gecko - there has been at least talk about this,
although apparently no code yet, at least not in CVS - there's no
guarantee that gtkhtml2 will still be shipped with the desktop. After
all, it's not part of the platform. If that happens, sticking with
gtkhtml2 will be more difficult.

> Concerning UI, it might
> be good to have ONE other option for setups where real estate on screen
> is important. But it should be designed very carefully.

Well, the thing is, these are just the same widgets organized
differently in containers. It wouldn't add any run-time complexity to
support this kind of thing; possibility something at the time of loading
up the UI, but after that, it's just business as usual.

But no need to worry, as I said, it's not going to happen any time soon.
It's a low-priority task.

-- 
[ Juri Pakaste | address@hidden | http://www.iki.fi/juri/ ]

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]