ReactOS UI Team - Concept, Plan, and: help wanted

[Aleksey Bragin]

Hi, our UI Team Coordinator - mf - asked me to sent this email on his  
behalf, because unfortunately mails from his address doesn't reach  
any mailing-list.

Here is the original message:
From: mf <mf(a)mufunyo.net>
Date: October 6, 2005 1:20:56 AM GMT+04:00
Subject: ReactOS UI Team - Concept, Plan, and: help wanted


Greetings ReactOS developers and interested parties!

For the unintroduced, I am your humble UI coordinator. In addition, I  
also made some graphics for the project.

-Concept-
I am here to remind you of a post that was made in the ReactOS user  
forum, written by crappish (Mikko Tikkanen). In it the author wrote  
of the need of a consistent user interface, the need of people that  
actually have knowledge of such things, and how these people would  
have to be in charge of enforcing such an interface. They should be  
familiar with Windows, know how to make things accessible and newbie- 
friendly, and have enough creativity to improve on existing concepts.  
In addition to that, there should be someone who represents this team  
and can interface it with the rest of the project, and make sure  
everything is the way everyone wants it to be. Now, this  
representative has been chosen. But there is no team to back him up!

-Recruiting-
So getting down to business. The UI team is recruiting two kinds of  
people.
Primarily: Programmers who have sufficient knowledge to hack other  
people's code, even if said code is rooted deeply in system  
libraries. Skill in writing user interfaces and piecing together  
dialog resources. No advanced skills beyond that required. This is  
most important, since developers in this category can get straight to  
business and get started on improving ReactOS.
Secondarily: Interface concept designers who have advanced knowledge  
of human interfacing, easy access, logical positioning, and the  
creativity to improve and expand on existing ideas. This is a  
secondary category because a) right now there is little to do in this  
respect, b) there are already two (counting Mikko?) of these people  
in ReactOS, and c) for every 1 concept designer, there can be up to  
10 implementing developers.
Even more appreciated, would be someone who fits both gloves and can  
write code AND design interfaces. Sadly, experience proves that these  
two traits don't usually come together in one person.

And! Just as important, though not actively recruited, I welcome icon  
designers, graphic designers, font designers (that includes you,  
wierd_w!), sound effect samplers, and programmers willing to  
implement missing UI features (think of things such as extended  
cursor/icon support, alpha blitting, runtime freetype configuration,  
recycle bin functionality, control panel, autorun support, etc), on  
individual application (mail me at mf(a)mufunyo.net).

-Plan-
The plan(tm) to kickstart the UI team is as follows:
Our first goal will be to make the surface experience of ReactOS  
familiar. Surface in this context means the things a user will see  
during and after bootup. This mainly involves modifying explorer; to  
display a consistent and familiar start menu, and to show a friendly  
explorer when My Computer or the Explore link is opened. This means  
making all the surface icons consistent (my task), modifying  
explorer's interface (the 'programmer' category), and figuring out  
the best layout for the start menu (the 'designer' category).
There is no plan past this first task, because I cannot predict how  
small or big the team is going to be, what feedback we are going to  
get, and how fast things will move.



And that's it for my first big announcement. I hope this will get  
some discussion going, and some balls rolling. I would also like to  
take this  opportunity to request a mailing list for the UI team,  
this should have been set up right after the coordinator vote was  
over, but it wasn't-- so to whoever's in charge of that, I count on  
you. Thanks.
Please reply to this mail only on the general list or to me in person  
(if you're not on the list and only get digests), it is only  
crossposted in ros-dev to get a wider range of attention.


Thanks for reading,
mf.

[WaxDragon]

>   -Recruiting-
>  So getting down to business. The UI team is recruiting two kinds of people.
>  Primarily: Programmers who have sufficient knowledge to hack other people's
>  code, even if said code is rooted deeply in system libraries. Skill in
>  writing user interfaces and piecing together dialog resources. No advanced
>  skills beyond that required. This is most important, since developers in
>  this category can get straight to business and get started on improving
>  ReactOS. 
Clearly outline the change desired, and file a enhancement bug on it,
you can point people to it that may be interested, and you may have
someone from another skill set implement it.  I think this is the best
method possible.  Keep in mind that Martin Fuchs is the maintainer of
explorer, so he may have a say on changes.  I would even recommend a
branch.

>   Secondarily: Interface concept designers who have
> advanced knowledge of
>  human interfacing, easy access, logical positioning, and the creativity to
>  improve and expand on existing ideas. This is a secondary category because
>  a) right now there is little to do in this respect, b) there are already two
>  (counting Mikko?) of these people in ReactOS, and c) for every 1 concept
>  designer, there can be up to 10 implementing developers.
>  Even more appreciated, would be someone who fits both gloves and can write
>  code AND design interfaces. Sadly, experience proves that these two traits
>  don't usually come together in one person.
>
>  And! Just as important, though not actively recruited, I welcome icon
>  designers, graphic designers, font designers (that includes you, wierd_w!),
>  sound effect samplers, and programmers willing to implement missing UI
>  features (think of things such as extended cursor/icon support, alpha
>  blitting, runtime freetype configuration, recycle bin functionality, control
>  panel, autorun support, etc), on individual application (mail me at
>  mf(a)mufunyo.net). 
Come up with a list of things needed, and put them on the wiki. You
never know who will help, but it needs to be publicly documented.

>   -Plan-
>  The plan(tm) to kickstart the UI team is as follows:
>  Our first goal will be to make the surface experience of ReactOS familiar.
>  Surface in this context means the things a user will see during and after
>  bootup. This mainly involves modifying explorer; to display a consistent and
>  familiar start menu, and to show a friendly explorer when My Computer or the
>  Explore link is opened. This means making all the surface icons consistent
>  (my task), modifying explorer's interface (the 'programmer' category), and
>  figuring out the best layout for the start menu (the 'designer' category).
>  There is no plan past this first task, because I cannot predict how small or
>  big the team is going to be, what feedback we are going to get, and how fast
>  things will move. 
You need to have a documented plan in an asynchronous environment,
such as this.  I'm learning this as the Testing Coordinator.

WD
--
<arty> don't question it ... it's clearly an optimization

[Martin Fuchs]

Hello,

> >   So getting
> > down to business. The UI team is recruiting two kinds of people.
> >  Primarily: Programmers who have sufficient knowledge to hack other people's
> >  code, even if said code is rooted deeply in system libraries. Skill in
> >  writing user interfaces and piecing together dialog resources. No advanced
> >  skills beyond that required. This is most important, since developers in
> >  this category can get straight to business and get started on improving
> >  ReactOS. 
>  Clearly outline the change desired, and file a enhancement bug on it,
>  you can point people to it that may be interested, and you may have
>  someone from another skill set implement it.  I think this is the best
>  method possible.  Keep in mind that Martin Fuchs is the maintainer of
>  explorer, so he may have a say on changes.  I would even recommend a
>  branch. 
[..]

>   Come up with a list of things needed, and put them on
> the wiki. You
>  never know who will help, but it needs to be publicly documented. 
Yes, that's the best way: Write down what you intend to implement
exactly on the Wiki or in Bugzilla. I will help in explorer, winefile
and ibrowser as far as possible. But my available time is limited.
Branching the code is possible, if you want to change explorer
completely. But I would prefer to maintain only one code base. The
already existing "lean-explorer" branch may be enough.  ;-)

Regards,

   Martin

[Jason Filby]

On 10/6/05, WaxDragon <waxdragon(a)gmail.com> wrote:
>   You need to have a documented plan in an asynchronous
> environment,
>  such as this.  I'm learning this as the Testing Coordinator. 
Did I miss something? I didn't realize we had a Testing Coordinator!
Not that I mind too much, but was this voted on? I've been a bit out
of it recently, so I may have missed it ;)

Cheers
Jason

[Rick Langschultz]

I agree with MF. I think the UI is inconsistent, but with some work  
it could be modified. I think that "explorer" should look something  
like Windows XP glitzed up ui, however may i suggest taking parts  
from firefox or something to create Javascript type collapsable  
panels like that of XP's explorer. Of course this could be turned  
off. I think that another feature could be incorporated into  
something like this... XML-based right-pane context menus. The  
context menus would be based off of XML files either embedded within  
explorer or in a subfolder in C:\reactos. These XML files would  
contain macros for quick tasks. Example:

<ContextMenu>
     <Action trigger="click">
         <Command execute="Explorer.Copy.FolderOrFile.getCurrentFile">

Of course there would be many commands and contexts, but this would  
allow users to define XML style macros. Call it something like  
AppleScript
On Oct 6, 2005, at 1:50 PM, Aleksey Bragin wrote:

>   Hi, our UI Team Coordinator - mf - asked me to sent
> this email on  
>  his behalf, because unfortunately mails from his address doesn't  
>  reach any mailing-list.
>
>  Here is the original message:
>  From: mf &lt;mf(a)mufunyo.net&gt;
>  Date: October 6, 2005 1:20:56 AM GMT+04:00
>  Subject: ReactOS UI Team - Concept, Plan, and: help wanted
>
>
>  Greetings ReactOS developers and interested parties!
>
>  For the unintroduced, I am your humble UI coordinator. In addition,  
>  I also made some graphics for the project.
>
>  -Concept-
>  I am here to remind you of a post that was made in the ReactOS user  
>  forum, written by crappish (Mikko Tikkanen). In it the author wrote  
>  of the need of a consistent user interface, the need of people that  
>  actually have knowledge of such things, and how these people would  
>  have to be in charge of enforcing such an interface. They should be  
>  familiar with Windows, know how to make things accessible and  
>  newbie-friendly, and have enough creativity to improve on existing  
>  concepts. In addition to that, there should be someone who  
>  represents this team and can interface it with the rest of the  
>  project, and make sure everything is the way everyone wants it to  
>  be. Now, this representative has been chosen. But there is no team  
>  to back him up!
>
>  -Recruiting-
>  So getting down to business. The UI team is recruiting two kinds of  
>  people.
>  Primarily: Programmers who have sufficient knowledge to hack other  
>  people's code, even if said code is rooted deeply in system  
>  libraries. Skill in writing user interfaces and piecing together  
>  dialog resources. No advanced skills beyond that required. This is  
>  most important, since developers in this category can get straight  
>  to business and get started on improving ReactOS.
>  Secondarily: Interface concept designers who have advanced  
>  knowledge of human interfacing, easy access, logical positioning,  
>  and the creativity to improve and expand on existing ideas. This is  
>  a secondary category because a) right now there is little to do in  
>  this respect, b) there are already two (counting Mikko?) of these  
>  people in ReactOS, and c) for every 1 concept designer, there can  
>  be up to 10 implementing developers.
>  Even more appreciated, would be someone who fits both gloves and  
>  can write code AND design interfaces. Sadly, experience proves that  
>  these two traits don't usually come together in one person.
>
>  And! Just as important, though not actively recruited, I welcome  
>  icon designers, graphic designers, font designers (that includes  
>  you, wierd_w!), sound effect samplers, and programmers willing to  
>  implement missing UI features (think of things such as extended  
>  cursor/icon support, alpha blitting, runtime freetype  
>  configuration, recycle bin functionality, control panel, autorun  
>  support, etc), on individual application (mail me at mf(a)mufunyo.net).
>
>  -Plan-
>  The plan(tm) to kickstart the UI team is as follows:
>  Our first goal will be to make the surface experience of ReactOS  
>  familiar. Surface in this context means the things a user will see  
>  during and after bootup. This mainly involves modifying explorer;  
>  to display a consistent and familiar start menu, and to show a  
>  friendly explorer when My Computer or the Explore link is opened.  
>  This means making all the surface icons consistent (my task),  
>  modifying explorer's interface (the 'programmer' category), and  
>  figuring out the best layout for the start menu (the 'designer'  
>  category).
>  There is no plan past this first task, because I cannot predict how  
>  small or big the team is going to be, what feedback we are going to  
>  get, and how fast things will move.
>
>
>
>  And that's it for my first big announcement. I hope this will get  
>  some discussion going, and some balls rolling. I would also like to  
>  take this  opportunity to request a mailing list for the UI team,  
>  this should have been set up right after the coordinator vote was  
>  over, but it wasn't-- so to whoever's in charge of that, I count on  
>  you. Thanks.
>  Please reply to this mail only on the general list or to me in  
>  person (if you're not on the list and only get digests), it is only  
>  crossposted in ros-dev to get a wider range of attention.
>
>
>  Thanks for reading,
>  mf.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Rick Langschultz
rlangschultz(a)cox.net (Home)
rlangschultz(a)ellemaespa.com (Work)
rlangschultz(a)email.uophx.edu (School)

[Maritn "E.T." Misuth]

Just a stupid idea,

why not fully Mozilla's embrace XPUI ( maybe with some micro aditions)
and use it for everythnig GUI related?

I mean, if I got it right from what I was reading, XPUI is XML system
for describing GUI layout and is binded to C++ code which forms
application. This way application programmer is fully shielded from
programming UI's and inversely UI designer can design almost anything
without the need to recompile the whole stuff. This allows to change
UI's really quickly and test several concepts without even changing the
actual code in app. Try opening FireFox AboutBox within browser tab
using chrome:\\ url or even try to open the browser window with
menubars, tabs and everything within itself, and you'll get what I mean.
Gecko is said to be fast so this shouldn't be a problem. Possiblities to
completely change UIs are then endless and can be done relatively
quickly and I bet that even those theme wankers would be happy with
something like that. Even twisted M$ is going to use some XML crap for
their GUI description system and I bet sooner or later Linux and the
rest of the world will follow (if it already there isn't some own work
like that). XPUI is there, I know it might not be the best XML UI
solution, but it is open source and already present, so I was thinking
it might be good idea. Anyone who has some background in html and
javascript can extend such resources, plus icons can be PNG's which are
really portable. Sure the apps might get bigger but some can get
smaller, and with todays HDD's this shouldn't be a problem. And mainly,
once such XPUI port will be done, FireFox for ReactOS download could be
made, propably, smaller because that XPUI library would be core part of
the system ;)...

You know my dream is having cool HW openGL accelerated XML based Windows
Classic like UI with SVG icons, which is pure utopia as I, myself, am
not able to code such a thing ;)) (but I dream and hope that someone
will) :)

And remember this is just stupid idea.
 
E.T.

[David Hinz]

Maritn "E.T." Misuth schrieb:

>  Just a stupid idea,
>
> why not fully Mozilla's embrace XPUI ( maybe with some micro aditions)
> and use it for everythnig GUI related?
>
> I mean, if I got it right from what I was reading, XPUI is XML system
> for describing GUI layout and is binded to C++ code which forms
> application. This way application programmer is fully shielded from
> programming UI's and inversely UI designer can design almost anything
> without the need to recompile the whole stuff. This allows to change
> UI's really quickly and test several concepts without even changing the
> actual code in app. Try opening FireFox AboutBox within browser tab
> using chrome:\\ url or even try to open the browser window with
> menubars, tabs and everything within itself, and you'll get what I mean.
> Gecko is said to be fast so this shouldn't be a problem. Possiblities to
> completely change UIs are then endless and can be done relatively
> quickly and I bet that even those theme wankers would be happy with
> something like that. Even twisted M$ is going to use some XML crap for
> their GUI description system and I bet sooner or later Linux and the
> rest of the world will follow (if it already there isn't some own work
> like that). XPUI is there, I know it might not be the best XML UI
> solution, but it is open source and already present, so I was thinking
> it might be good idea. Anyone who has some background in html and
> javascript can extend such resources, plus icons can be PNG's which are
> really portable. Sure the apps might get bigger but some can get
> smaller, and with todays HDD's this shouldn't be a problem. And mainly,
> once such XPUI port will be done, FireFox for ReactOS download could be
> made, propably, smaller because that XPUI library would be core part of
> the system ;)...
>
> You know my dream is having cool HW openGL accelerated XML based Windows
> Classic like UI with SVG icons, which is pure utopia as I, myself, am
> not able to code such a thing ;)) (but I dream and hope that someone
> will) :)
>
> And remember this is just stupid idea.
>  
> E.T.
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   
>  
Actually I don't think, that this is just a stupid idea.

I thought of writing the whole UI in a new language, that is HTML/PHP like and can use
something like AppleScript.
The whole UI would be some kind of webpage, but the language would be completely new
designed, so that ii is not static and needs to be reloaded after some time.
You could have something like frames and iframes, which can be moved over the whole
screen.
That would be a big thing to implement, but everybody can then easily write a new UI the
way he likes.

Just anoher stupid idea...

Greets,

David Hinz

[Rick Langschultz]

Actually a utility or an explorer like integration with a scripting  
language would be a great idea for reactos, however I don't think it  
is ready for such a feature yet.
I have been working on a port of a product which is very critical to  
development of reactos, however i don't want to share what it is yet...

lets just say reactos will be up to speed on internet serving when  
TCP/IP gets up and running... in the form of application servers.
On Oct 12, 2005, at 6:35 AM, David Hinz wrote:

>   Maritn "E.T." Misuth schrieb:
>
>
> >   Just a stupid idea,
> >
> >  why not fully Mozilla's embrace XPUI ( maybe with some micro  
> >  aditions)
> >  and use it for everythnig GUI related?
> >
> >  I mean, if I got it right from what I was reading, XPUI is XML system
> >  for describing GUI layout and is binded to C++ code which forms
> >  application. This way application programmer is fully shielded from
> >  programming UI's and inversely UI designer can design almost anything
> >  without the need to recompile the whole stuff. This allows to change
> >  UI's really quickly and test several concepts without even  
> >  changing the
> >  actual code in app. Try opening FireFox AboutBox within browser tab
> >  using chrome:\\ url or even try to open the browser window with
> >  menubars, tabs and everything within itself, and you'll get what I  
> >  mean.
> >  Gecko is said to be fast so this shouldn't be a problem.  
> >  Possiblities to
> >  completely change UIs are then endless and can be done relatively
> >  quickly and I bet that even those theme wankers would be happy with
> >  something like that. Even twisted M$ is going to use some XML crap  
> >  for
> >  their GUI description system and I bet sooner or later Linux and the
> >  rest of the world will follow (if it already there isn't some own  
> >  work
> >  like that). XPUI is there, I know it might not be the best XML UI
> >  solution, but it is open source and already present, so I was  
> >  thinking
> >  it might be good idea. Anyone who has some background in html and
> >  javascript can extend such resources, plus icons can be PNG's  
> >  which are
> >  really portable. Sure the apps might get bigger but some can get
> >  smaller, and with todays HDD's this shouldn't be a problem. And  
> >  mainly,
> >  once such XPUI port will be done, FireFox for ReactOS download  
> >  could be
> >  made, propably, smaller because that XPUI library would be core  
> >  part of
> >  the system ;)...
> >
> >  You know my dream is having cool HW openGL accelerated XML based  
> >  Windows
> >  Classic like UI with SVG icons, which is pure utopia as I, myself, am
> >  not able to code such a thing ;)) (but I dream and hope that someone
> >  will) :)
> >
> >  And remember this is just stupid idea.
> >  E.T.
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  
>  Actually I don't think, that this is just a stupid idea.
>
>  I thought of writing the whole UI in a new language, that is HTML/ 
>  PHP like and can use something like AppleScript.
>  The whole UI would be some kind of webpage, but the language would  
>  be completely new designed, so that ii is not static and needs to  
>  be reloaded after some time.
>  You could have something like frames and iframes, which can be  
>  moved over the whole screen.
>  That would be a big thing to implement, but everybody can then  
>  easily write a new UI the way he likes.
>
>  Just anoher stupid idea...
>
>  Greets,
>
>  David Hinz
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
Rick Langschultz
rlangschultz(a)cox.net (Home)
rlangschultz(a)ellemaespa.com (Work)
rlangschultz(a)email.uophx.edu (School)

[Maritn "E.T." Misuth]

Rick Langschultz wrote:
>   Actually a utility or an explorer like integration
> with a scripting 
>  language would be a great idea for reactos, however I don't think it  is
>  ready for such a feature yet. 
I was rather thinking about using XUL to define UI
interfaces for almost every
native ReactOS app from regedit to mmc equivalent. Maybe even translation could
simplified this way ;)), just replug XML interface files with that of another
language. Just my thoughts...

[Robert Köpferl]

I think that's a bad idea.
There're too much XML describing a GUI projects out there. Why make 
another 3?
We'd rather orient in this case on M$ and further work with RC-files. 
Despite of their static sizing character. This (also xmlish) avalon is 
ont thing i don't really like, but it's one think, i think we have to 
implement. At least it will wipe away sizing problems. But apps get 
heavier and file-ier and slower and xmlisher. All negative.

Maritn "E.T." Misuth wrote:
>   Rick Langschultz wrote:
>  
> >  Actually a utility or an explorer like integration
> > with a scripting 
> > language would be a great idea for reactos, however I don't think it  is
> > ready for such a feature yet. 
>  
>  I was rather thinking about using XUL to define UI interfaces for almost every
>  native ReactOS app from regedit to mmc equivalent. Maybe even translation could
>  simplified this way ;)), just replug XML interface files with that of another
>  language. Just my thoughts...
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Rick Langschultz]

I think ReactOS would benefit from something like an xml interfacing  
scripting language to ReactOS. Something like applescript, but i was  
thinking integration with the Mono project could greatly increase the  
feasibility of this type of interface. The interfacing scripting  
language could be available in the C# language. Of course mcs would  
have to be integrated into some sort of system service. But first  
reactos needs to have system services and file system protection in  
place before this model fully works.
On Oct 12, 2005, at 5:07 PM, Robert Köpferl wrote:

>   I think that's a bad idea.
>  There're too much XML describing a GUI projects out there. Why make  
>  another 3?
>  We'd rather orient in this case on M$ and further work with RC- 
>  files. Despite of their static sizing character. This (also xmlish)  
>  avalon is ont thing i don't really like, but it's one think, i  
>  think we have to implement. At least it will wipe away sizing  
>  problems. But apps get heavier and file-ier and slower and  
>  xmlisher. All negative.
>
>  Maritn "E.T." Misuth wrote:
>
> >   Rick Langschultz wrote:
> >
> > >   Actually a utility or an explorer like
> > > integration with a  
> > >  scripting language would be a great idea for reactos, however I  
> > >  don't think it  is
> > >  ready for such a feature yet.
> > >  
> >  I was rather thinking about using XUL to define UI interfaces for  
> >  almost every
> >  native ReactOS app from regedit to mmc equivalent. Maybe even  
> >  translation could
> >  simplified this way ;)), just replug XML interface files with that  
> >  of another
> >  language. Just my thoughts...
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
Rick Langschultz
rlangschultz(a)cox.net (Home)
rlangschultz(a)ellemaespa.com (Work)
rlangschultz(a)email.uophx.edu (School)

[David Hinz]

Rick Langschultz schrieb:

>   I think ReactOS would benefit from something like an
> xml interfacing  
>  scripting language to ReactOS. Something like applescript, but i was  
>  thinking integration with the Mono project could greatly increase the  
>  feasibility of this type of interface. The interfacing scripting  
>  language could be available in the C# language. Of course mcs would  
>  have to be integrated into some sort of system service. But first  
>  reactos needs to have system services and file system protection in  
>  place before this model fully works.
>  On Oct 12, 2005, at 5:07 PM, Robert Köpferl wrote:
>
> >   I think that's a bad idea.
> >  There're too much XML describing a GUI projects out there. Why make  
> >  another 3?
> >  We'd rather orient in this case on M$ and further work with RC- 
> >  files. Despite of their static sizing character. This (also xmlish)  
> >  avalon is ont thing i don't really like, but it's one think, i  think 
> >  we have to implement. At least it will wipe away sizing  problems. 
> >  But apps get heavier and file-ier and slower and  xmlisher. All 
> >  negative.
> >
> >  Maritn "E.T." Misuth wrote:
> >
> > >   Rick Langschultz wrote:
> > >
> > > >   Actually a utility or an explorer like
> > > > integration with a  
> > > >  scripting language would be a great idea for reactos, however I  
> > > >  don't think it  is
> > > >  ready for such a feature yet.
> > > >  
> > >  I was rather thinking about using XUL to define UI interfaces for  
> > >  almost every
> > >  native ReactOS app from regedit to mmc equivalent. Maybe even  
> > >  translation could
> > >  simplified this way ;)), just replug XML interface files with that  
> > >  of another
> > >  language. Just my thoughts...
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  Rick Langschultz
>  rlangschultz(a)cox.net (Home)
>  rlangschultz(a)ellemaespa.com (Work)
>  rlangschultz(a)email.uophx.edu (School)
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
I think scripting like AppleScript is very important. And xml 
interfacing like XUL is a nice feature, but we don't need it at the moment.
But the earlier we integrate something like that, the more resources we 
save. Integrating XUL needs a lot of work, I think a lot of thing need 
to be rewritten.

Greets,

David Hinz

[KJKHyperion]

Maritn "E.T." Misuth wrote:

>  why not fully Mozilla's embrace XPUI ( maybe with
> some micro aditions) and use it for everythnig GUI related?
>   
>  
no

[Rick Langschultz]

I also see a problem with this. Mozilla's XPUI has some great  
features however I do think it is drawing away from the goals of  
reactos. WSH and Applescript provide interfaces for accessing and  
automating system events however some people might not want such  
features in their installation. I think something like a scriptable  
interface should be an addon to the installation of reactos much like  
IIS is an addon to any NT based installation like 2000, XP Pro, and  
2003. I am however writing ports for OpenLDAP, Jabber, Apache 2.0,  
Tomcat, MaxDB, Postgresql, and MySQL for reactos, but without  
networking and service support my efforts are restricted to windows  
2000.
On Oct 13, 2005, at 6:27 AM, KJKHyperion wrote:

>   Maritn "E.T." Misuth wrote:
>
>
> >   why not fully Mozilla's embrace XPUI ( maybe
> > with some micro  
> >  aditions) and use it for everythnig GUI related?
> >
> >  
>  no
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
Rick Langschultz
rlangschultz(a)cox.net (Home)
rlangschultz(a)ellemaespa.com (Work)
rlangschultz(a)email.uophx.edu (School)