Ros-dev

ros-dev@reactos.org

5790 discussions

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

by 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.

20 years

Problem with VMware Workstation 5.5

by Mike Swanson

for the most part, all is well. However, upon the installation of video drivers using the VMware Tools ISO, ReactOS fails to install the driver. I believe this is simply because of a new directory structure to accomodate both 32-bit and 64-bit Windows operating systems.. 32-bit driver: D:\program files\VMware\VMware Tools\Drivers\video\winnt2k\32Bit 64-bit driver (probably not wanted unless someone's doing a x86_64 port): D:\program files\VMware\VMware Tools\Drivers\video\winnt2k\64Bit -- Mike

20 years

RE: [ros-dev] A call for 0.2.8

by Murphy, Ged (Bolton)

Wow, there's no flies on you ;) -----Original Message----- From: WaxDragon [mailto:waxdragon@gmail.com] Sent: 12 October 2005 14:43 To: ReactOS Development List Subject: Re: [ros-dev] A call for 0.2.8 I was hoping to get it branched today, do a baseline test and have an RC1 for this weekend. If Brandon does the release, that would help me out. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

20 years

Font problem on Japanese version of ReactOS

by tsk

I made Japanese version of ReactOS. Following is all that I have done. 1) add jpn.nls to \lib\kernel32\nls\ 2) modify \lib\kernel32\locale_rc.rc 3) add Japanese font to \media\fonts\ 4) add next line to \bootdata\hivesft.inf HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\SysFontSubstitutes","MS UI Gothic",0x0000 0000,"FontName" 5) add next line to \bootdata\packages\reactos.dff media\fonts\FontName.ttf 3 6) modify locale settings at \bootdata\hivesft.inf and hivesys.inf HKCU,"Control Panel\International","Locale",0x00000000,"0411" HKLM,"SYSTEM\CurrentControlSet\Control\NLS\Language","Default",0x00000000,"0411" HKLM,"SYSTEM\CurrentControlSet\Control\NLS\Language","InstallLanguage",0x00000000,"0411" Now please look at these screenshots. http://reactos-j.sourceforge.jp/up/img/081.png http://reactos-j.sourceforge.jp/up/img/082.png The former uses mona http://monafont.sourceforge.net/index-e.html The latter uses mplus http://www.kaoriya.net/#BDFM+ I'm very sad... Is ReactOS able to handle Japanese font properly?

20 years

Re: [ros-svn] [ekohl] 18383: First shot at CreateServiceW. It crashes due to a bug (aka missing feature) in widl. = ROS BUILD FAILED

by Gge

ekohl(a)svn.reactos.com wrote: > First shot at CreateServiceW. It crashes due to a bug (aka missing feature) in widl. I'm going to fix it as soon as possible. > > > Updated files: > trunk/reactos/include/idl/svcctl.idl > trunk/reactos/lib/advapi32/service/scm.c > trunk/reactos/subsys/system/services/database.c > trunk/reactos/subsys/system/services/rpcserver.c > trunk/reactos/subsys/system/services/services.c > trunk/reactos/subsys/system/services/services.h > Hello, This change brokes Ros - It fails to build with the following errors : [CC] lib\advapi32\service\eventlog.c [CC] lib\advapi32\service\scm.c lib\advapi32\service\scm.c: In function `CreateServiceW': lib\advapi32\service\scm.c:271: warning: implicit declaration of function `ScmrCreateServiceW' mingw32-make: *** [obj-i386\lib\advapi32\service\scm.o] Error 1 R18382 builds fine Regards Gge

20 years

RE: [ros-dev] A call for 0.2.8

by Murphy, Ged (Bolton)

Robert wrote: > This would still work out with my plans. > I'll be able to do this release. BTW I intended to document and > rbuildify (or the like) the process Can we branch for this sooner rather than later. What about this weekend? ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

20 years

Re: [ros-diffs] [gvg] 18410: Terminate the new environment with a NULL pointer

by Gunnar Dalsnes

There are probably dozens of bugs like that lurking around in crt, exposed by malloc not zeroing memory anymore... gvg(a)svn.reactos.com wrote: > Terminate the new environment with a NULL pointer > > Modified: trunk/reactos/lib/crt/misc/environ.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/crt/misc/environ.c* > > --- trunk/reactos/lib/crt/misc/environ.c 2005-10-12 08:38:45 UTC (rev 18409) > +++ trunk/reactos/lib/crt/misc/environ.c 2005-10-12 13:00:34 UTC (rev 18410) > @@ -178,6 +178,7 @@ > > return original_environment; > } > } > > + *newenvptr = NULL; > > > return newenv; > } >

20 years

Idea for a new part in headers of .rc files

by David Hinz

Hey guys, when I just translated format, I stunbled over one thing: What if somebody changed the content of a string after I translated it? After some minutes, I had a easy solution for that problem: The En.rc gets a little line in it's head-comment with a revision number. Each time somebody changes or adds a string in the En.rc, he sets the revision number +1 and so all translators have an easy to control indicator, if they need to translate something or not. But I think one thing should be clear, if there just has been corrected a spelling mistake and not something important, the revision number won't be touched. Now some example headers: in the EN.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * * Revision: 1 */ in my De.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * First German Translation by David Hinz 20051010 * * Translated Revision 1 of En.rc */ This is just an idea, but I think this could save a lot of work on bigger applications than format... Greets, David Hinz

20 years

Re: [ros-dev] ReactOS UI Team - Concept, Plan, and: help wanted

by Maritn "E.T." Misuth

To my knowledge, it is completely posible to write helper apps in JavaScript to function with XUL. At least as extension modules for apps already using the whole thing. For example I think that ChatZilla extension for mozilla is written that way, in pure JavaScript. But if XUL can be used as a core part of some system's dialog/windows rendering I think it is completely possible to create relatively simple facility to have complete standalone apps in JavaScript. It's a long time since I've played with XUL, but if you have FireFox, you can start to play with it right now, and create for example simple dialogs & windows with radio buttons etc using that language and CSS styles. PS: Yes it was an accindent, I wanted to send the mail to the list, sorry ;).

20 years

RE: [ros-dev] RE: Ros-dev Digest, Vol 14, Issue 25

by Murphy, Ged (Bolton)

I'm not quite sure what everyone is getting at here. Every file has it's entire history logged, easily accessible through your local tree under the context menu, or through Viewcvs on the web. Changes also go out through the svn mailing list. Any closer queries can me viewed via 'diff'ing to any revision you want. However, it would be easy to write a quick tool to assess local timestamps after svn updates for set file types. This would quickly tell you what has changed without the need for viewing the svn logs. Ged. -----Original Message----- From: David Hinz [mailto:post.center@gmail.com] Sent: 12 October 2005 13:12 To: ReactOS Development List Subject: Re: [ros-dev] RE: Ros-dev Digest, Vol 14, Issue 25 Well, the thing is I wanted to have something that makes it very easy to see, if something has changed since the last time I translated that file. Watching the svn all the time is not that easy than just looking at a number. There could also be a little helper app that scans all .rc files in my language and all en.rcs for revision differences and shows me, where I have to translate something. Then I can look in the svn what actually has been changed. It just makes things easier for translators. Greets, David Hinz ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

20 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev