Hi,
I have read a bit of your homepage and a bit of the mailinglists.
Some people complained about the quite "ugly" GUI. Here my suggestion: Do not
put your energy in improving the GUI for ReactOS. It would be nice when
ReactOS will run on slow and older machines, too. But a ReactOS-Distro could
include KDE (or GNOME) as default GUI. There will be a KDE- and a
GNOME-version for Windows in a year or so. Hence it will also run on ReactOS
(at least theoratically). So people who like to have a marvelous looking
desktop enviroment can use KDE or GNOME. Besides there will be dozens of
usefull application (just think of Kate, K3B, Kile, AmaroK, Konqueror,
KOffice, KMail, Kontact, ...).
A ReactOS-Distro could, of couse, include all those packages and a
linux-distro-like package manager. It would be great to see mingw-, qt-,
gtk-, wx-, gnome- and kde-dlls. This would make a ReactOS-Distro very thin
and lean because - for instance - every wx-application can link dynamically
against the wx-library and so on.
--
Greetz,
Roland
I must agree with Robert.
Many competent people have tried to make the GUI "all things to all people".
It's a problem which lies at the very foundation of all the popular Open Source platforms, particularly Linux and Windows. I constantly keep reminding myself of that.
My interest in ROS came form the original FreeDOS and so far the ROS team has managed to stay true to freeDOS founding principles.
Above all plug-in replaceability with the core elements of DOS.
Congratualtions so far.
In spite of overwhelming increase in feature demand, beginning with multasking, ROS is keeping up.
What made it easier for me to stick with ROS is the knowledge that, behind the scenes a lot of ground-breaking "core" work is being done by other Open Source groups.
For example: MinGW-Msys.
It is the most impressive so far.
They (if I understand them properly) have stepped back to the very roots of Unix and the Bourne (again) Shell i.e BASH.
>From that stable base they have taken the line that both Windows and Linux and some other proprietry platforms like Apple all rely on "C" at some point.
They too are faceing "Feature and Transaction pressure", but through good planning they are keeping up with ,and in some places overtaking, all of the rich platform giants.
It is really up to the "feature enthusiasts" to take more resonsibilty onto themselves.
That is: rtfm, or do the homework. How often have I forgotten that advice.
Unlike some other open groups, the ROS team is respectful and tolerant, even if they do get a little touchy.
Regards and rosuccess.
Justin
---- "Robert Köpferl" <rob(a)koepferl.de> wrote:
> Sorry, but technically it seems you have no clue.
> This gui stuff is difficult and not as easy as putting gt and k+ togehter.
>
> Think of event handling not just painting. Or why is Ooo still without
> Cocoa UI?
>
> Dmitrij D. Czarkoff wrote:
> > On Monday 17 October 2005 02:01, Mikko Tikkanen wrote:
> >
> >>Except that KDE or GNOME isn't really a Windows GUI nor can it run
> >>Windows software (presuming on the applications you mentioned)...
> >
> >
> > Still this idea could be usefull after some rethinking.
> > ReactOS has its own implementation of win32 apps' GUI. On the other hand, we
> > do have GTK+, Qt and some more crossplatform GUIs implemented on win32
> > platform. So we can pass all the widgets stuff to one of them and drop the
> > windows-native GUI (which is still slow and buggy). This would unify the GUI
> > of the system and make the system more stable while easier configurable. This
> > will let us use any popular X11 environment (or give a choise to user).
> > I think the preferable widget set would be GTK+ (because it's the most widely
> > spread among alternative widget sets and its license is safe) and the
> > preferable workspace would be GNOME (just because it's GTK+-based, popular
> > and actively developed).
> > Technically this approache means makeing all the Windows GUI-related libraries
> > the wrappers to the GTK libraries.
> > I think that such modification would be useful even without switching to some
> > DE or WM from Linux world just because GTK is off and ready, while ReactOS's
> > GUI is slow and buggy.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > ros-general mailing list
> > ros-general(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-general
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Hi folks,
did you already implement an replacement for the IE libraries
(and if not: is this planned anyway ?)
If I understood you correctly (at least in the discussions we
had last year), you're implementing the win32 APIs as exact
as possible. So would (at least the userland stuff) be
drop-in compatible with the orignal M$ code ?
It would be really nice to have dummies for the IE libraries,
to get IE off an Windows system, but remain it runnable.
Perhaps it would be even nicer to have IE libs using the
mozilla/gecko as backend ;-)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(a)metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
OK Richard, Now I understand ( I think).
I have a choice to start that "other project" or find it.
Well for the benefit of the listeners I have started it.
In the interests of [ros-general] please consider UAPI closed.
Any private suggestions are welcome.
Thanks and rosSuccess.
Justin
---- Richard Campbell <eek2121(a)comcast.net> wrote:
> Last i checked, the ROS design isn't designed to correct anything. It
> is designed to be a drop in replacement for Windows NT, 2000, XP that is
> compatible with applicatons and drivers. It is then up to other
> projects to mod that as they see fit.
>
> Richard
>
> Thomas Weidenmueller wrote:
>
> >jwalsh(a)bigpond.net.au wrote:
> >
> >
> >>The Original Windows is having anormous problems fighting off Virus and Malware.
> >>It is known that it's vunerability is builtin to its original design i.e. the TSR.
> >>Where does the ROS current design correct that inherent problem?
> >>
> >>
> >
> >If we can't run viruses designed for windows (except those exploiting
> >bugs), the level of compatibility is rather low...
> >
> >
> >
> >>If ROS is short staffed now how bad is it going to get, if and when things do take off.
> >>
> >>
> >
> >We're not going to have an OS that I would consider stable in the near
> >future. There are bugs and flaws everywhere you look, kind of the same
> >problem that wine has.
> >
> >
> >
> >>If a multi billion dollar enterprise cannot stop it how can ROS stop it?
> >>This is not a trivial question.
> >>
> >>
> >
> >Money can't fix everything, sometimes better decisions would help.
> >
> >- Thomas
> >_______________________________________________
> >ros-general mailing list
> >ros-general(a)reactos.org
> >http://www.reactos.org/mailman/listinfo/ros-general
> >
> >
> >
>
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Ok Thomas. I am beginning to understand.
I'm a bit slow. I saw it as merely providing a more stable Foundation for ROS, that is all.
If you are so unknowing of OSI, and API and all that stuff now, and do not care, then I am wasting your time.
Sorry.
Frankly, the Universal API is still only an Idea which never got off the ground about 25 years ago (because of in-fighting), but still does work in isolated practice.
>From the Email I am getting there is so much disagreement on this list you will need all you time and effort to keep it from collapsing.
In your best interest, please consider this topic closed.
Regards and Success
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
> jwalsh(a)bigpond.net.au wrote:
> > I'll switch to private mode, so as not to annoy the ros-general list.
> > It is a little off topic.
>
> I don't think that's a good idea, especially when I keep getting
> annoying spam approval emails which I won't approve.
>
> > I'll choose three references which I feel, by and large, describe the API.
> > The first also includes a reference to wine:
> > 1. http://www.absoluteastronomy.com/encyclopedia/a/ap/application_programming_…
> > 2. http://www.absoluteastronomy.com/encyclopedia/o/os/osi_model2.htm
> > 3. http://en.wikipedia.org/wiki/Layer_2
>
> I do know the OSI model and I do know what APIs are. I however don't
> know what exactly the UAPI is supposed to be. We're working on a windows
> compatible operating system. We do not plan to add ReactOS-specific
> APIs, so whatever UAPI is, unless it's an API provided by Windows,
> there's a low chance we'd ever implement it into the core code base.
>
> > What we expect to do, is study the "rats nest" of protocols and reduces them to a single Universal OSI Standard. We believer that hardware must dance to the tune of software, not the opposite.
> > We have some success at the Application Layer (level 7) already.
> > Here we can reduce many hundreds of applications to a single application, automatically.
> > Then we simply print of the "blueprint" i.e. Application Requirements Definition (ARD).
> > We then simply pass the ARD to the programmers to be put into code.
> > This way we have turned a medievel like craft into an industrial process.
> > In fact we are preparing to generate the code directly from the text based ARD.
>
> We can't change existing hardware, ReactOS is supposed to work on the
> existing platforms. What you described is extremely theoretical, I still
> don't really know what it is supposed to be. Most of us - i think - are
> more practical people, give us the detailed description of how the API
> is supposed to look like and what it should provide and we can do it.
> Discussing theories about APIs that don't exist (in Windows) doesn't
> make much sense I think.
>
> > We have reduced application development from months-years to hours-days.
>
> That's great, for ReactOS this is just not going to work.
>
> > Unfortunately, no matter how perfect our design is, it can only be as good as the weakest link.
> > We've found that weakest link hidden in the API itself, outside of our control.
> > Of course the hardware providers will not be happy with this development.
>
> Which leads to the question whether hardware depends on software or the
> other way around...
>
> > Neither will the software providers who write the drivers.
> > It must be, if it is to be backward (and forward) compatible, transparent to the any and every application.
> > Wine, in a sense is trying to acheive the same thing, by not trying to create a single standard, but merely an API adapter.
>
> Wine is all about creating a compatible implementation of the Win32 API.
>
> > Sorry again for being so long winded.
> > Hope that explains it
>
> Not really, sorry ;)
>
> So my final question about this - and I don't plan to spend any more
> time about this - is: Is this UAPI thing just a theory or actually an
> API that exists?
>
> - Thomas
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Hello All.
Just sending out an announcement that Issue 1 of the new ReactOS
Weekly Newsletter is now available for viewing on
http://www.reactos.org
Thanks to GvG for showing me the internals of RosCMS, Bac9 on #reactos
for helping with validation checks, and dnordenberg, again on
#reactos, for offering to help with the Newsletter in the form of an
XML-Based back-end, to come soon.
--
"I had a handle on life, but then it broke"
Good god...
"First off, judge yourself. Are you an experienced graphics
designer/artist with extensive icon experience? Have you ever made
icons included in other projects, such as at your day job, an open
source project, or similar? If you answered "no" to ANY of these
questions, please do not attempt to submit icons. Save yourself
humiliation, and save me the difficult task of turning you down. It's
not because I want to be mean, honestly. If you answered "yes" to all
of the above questions, please read on."
Is it just me or do anyone else get a _tad_ arrogant image from that?
This attitude has been a major setback, from the start, on my side and
it's starting to get under my skin again.
First of all, surely ROS isn't professional project, if it would be it
would have real funding etc. Besides, open source projects seldom are
for professionals only. In my point of view any kind of help would be
appreciated, but it seems that now only professionals can help.
Well, I think it's time to open up a bit.
mf: Last time, when I was about to lose it, you persistently you went
on (in forums and in IRC) how there is no "magical rules" and i.e. on
icon design and only rules applying are recognition and color use.
True; Recognition plays a cruicial role and it can be aided with
proper color use. False; There are other rules that need to be
considered, these are no less "magical" than say proper color use.
Well, for example, lets see your trashcan design:
http://www.mufunyo.net/reactos/trashcan.pnghttp://www.mufunyo.net/reactos/trashcan2.png
Now, can you tell me what's wrong with that desing? And in this case
I'm not referring to colors, shapes or anything like that...
-mikko
Hi all
I've decided that now is the best time to step down as Project
Coordinator. The process to vote for a new PC will be - as previously
decided for this type of decision - that only registered committers
can vote.
Regards
Jason
PS - I've cc'd the developers on leave as to not exclude anyone
Ok Thomas. I'll try and put it another way.
The Original Windows is having anormous problems fighting off Virus and Malware.
It is known that it's vunerability is builtin to its original design i.e. the TSR.
Where does the ROS current design correct that inherent problem?
If ROS is short staffed now how bad is it going to get, if and when things do take off.
If a multi billion dollar enterprise cannot stop it how can ROS stop it?
This is not a trivial question.
Thanks
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
> jwalsh(a)bigpond.net.au wrote:
> > Hi Al.
> >
> > Please correct me if I am being too naive.
> > But what you have just said makes so much sense to me.
> > The windowblinds will in fact be a matter for the CGI; separating the Form from the Content.
> > I think I understand what you have said as being a kind of UAPI: Universal Application Programming Interface.
> > I did a quick google on the abbrieviation and it does not yet exist. Only API.
> > I hate inventing new terms when old ones serve just as well, if not better.
> > However it comes from my old hardware days when the second biggest chip on the board was the UART: Universal Asynchronous Receiver Transmitter.
> > It was cleverly reduced by TI to a tiny 16 pin package, the rest done with a special 4KB bit memory and a few instructions.
> > It (the "UAPI") does pretty much the same thing which the Ethernet OSI 7 Layer Model tries to do. So far it The API looks and feels like software but is actually softWire, cleverly disguised.
> > I no NOT mean softwire as another name for software.
> > Idealy the "UAPI" reduces 7 layers of Meta-drivers to one Application.
> > The use of the word Ether (like softwire) in the Network also lends false credence to the meaning of the API.
> > The Ether was once thought to be Matterial which conducted light i.e. a kind of invisible wire. We now know it to be mere a Mode of the existence of Matter.
> > Not an Object in the real sense but a purely Mental one.
> > The concept may serve the interest of the Hardware (wire) Industry but not ours.
> > Our R&D team is working on this now.
> >
> > Thanks for the the enlightening thought
>
> ok....what? Sorry, can't follow...
>
> - Thomas
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
jwalsh(a)bigpond.net.au wrote:
> I'll switch to private mode, so as not to annoy the ros-general list.
> It is a little off topic.
I don't think that's a good idea, especially when I keep getting
annoying spam approval emails which I won't approve.
> I'll choose three references which I feel, by and large, describe the API.
> The first also includes a reference to wine:
> 1. http://www.absoluteastronomy.com/encyclopedia/a/ap/application_programming_…
> 2. http://www.absoluteastronomy.com/encyclopedia/o/os/osi_model2.htm
> 3. http://en.wikipedia.org/wiki/Layer_2
I do know the OSI model and I do know what APIs are. I however don't
know what exactly the UAPI is supposed to be. We're working on a windows
compatible operating system. We do not plan to add ReactOS-specific
APIs, so whatever UAPI is, unless it's an API provided by Windows,
there's a low chance we'd ever implement it into the core code base.
> What we expect to do, is study the "rats nest" of protocols and reduces them to a single Universal OSI Standard. We believer that hardware must dance to the tune of software, not the opposite.
> We have some success at the Application Layer (level 7) already.
> Here we can reduce many hundreds of applications to a single application, automatically.
> Then we simply print of the "blueprint" i.e. Application Requirements Definition (ARD).
> We then simply pass the ARD to the programmers to be put into code.
> This way we have turned a medievel like craft into an industrial process.
> In fact we are preparing to generate the code directly from the text based ARD.
We can't change existing hardware, ReactOS is supposed to work on the
existing platforms. What you described is extremely theoretical, I still
don't really know what it is supposed to be. Most of us - i think - are
more practical people, give us the detailed description of how the API
is supposed to look like and what it should provide and we can do it.
Discussing theories about APIs that don't exist (in Windows) doesn't
make much sense I think.
> We have reduced application development from months-years to hours-days.
That's great, for ReactOS this is just not going to work.
> Unfortunately, no matter how perfect our design is, it can only be as good as the weakest link.
> We've found that weakest link hidden in the API itself, outside of our control.
> Of course the hardware providers will not be happy with this development.
Which leads to the question whether hardware depends on software or the
other way around...
> Neither will the software providers who write the drivers.
> It must be, if it is to be backward (and forward) compatible, transparent to the any and every application.
> Wine, in a sense is trying to acheive the same thing, by not trying to create a single standard, but merely an API adapter.
Wine is all about creating a compatible implementation of the Win32 API.
> Sorry again for being so long winded.
> Hope that explains it
Not really, sorry ;)
So my final question about this - and I don't plan to spend any more
time about this - is: Is this UAPI thing just a theory or actually an
API that exists?
- Thomas
