Re: Record Button?



Dan Kaminsky <effugas@best.com> wrote:
> >one important rule of ui design is to NOT put rarely needed things anywhere
> >up front. put a record option in some menu, but don't create a new
> top-level
> >button for something that'll be used once a year.
> 
> Macros are something average users really *should* use more.

if indeed we can use xlab for macro recording. and that's a very big if,
unfortunatly.


> I'm beginning to see the value, however, in just leaving it in something
> like the gnomeprint menu you also don't like :-)

eh? who said I don't like the additional menu? I just call it "Prog", that's
all.



> >see, xlab replays, it's not smart. a macro might (and WILL) break just
> >because you have the window at a different size than the one who recorded
> >it.
> 
> That's how it works *now*.  You don't think this is changable?  Remember,
> we're the blue sky people.

maybe it is. but should we put features that may be a year away into
something we're developing NOW ?



> >tv's have a fixed screen size. (at least within the major systems, I'm not
> >sure if pal and ntsc use the same pixels.)
> >in addition, tv's have only one "user context" and no interaction.
> 
> For screenplays, context is fixed--the window is ALWAYS the correct size
> because it's generated by the playback.

playbacks - see below.
macros? nope. window is at whatever size the user has when he calls the
macro.

now for playbacks - if we want the playbacks to be gnome stuff, they have to
follow all things from internationalisation to different windowmanagers,
themes and what-else. you can NOT guarantee identical window layout under
that circumstances. or if you can I'd be eager to hear how.


-- 
The universe does not have laws -- it has habits, and habits can be broken.



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