> I see the problems now, thanks for the explanation. In that case, I would
> say between to equal methods, pick the one that leaves the door open for
> such future work, if anyone is inclined to do it.
that's also what I had in mind...
it's time now to go back to write actually what has been discu
On November 22, 2002 01:24 pm, Eric Pouech wrote:
> and in all the cases it creates a huge amount of code/work to be created
> (and I not even sure that's doable in a 100% bullet proof fashion)
I see the problems now, thanks for the explanation. In that case, I would
say between to equal methods,
"Dimitrie O. Paun" a écrit :
>
> On November 21, 2002 04:44 pm, Eric Pouech wrote:
> > this won't support the case where the app creates it own console after
> > it has started
>
> Duh! Forgot about that one. This is getting funny :) What about this one:
>
> When we create a console, we start
On November 21, 2002 04:44 pm, Eric Pouech wrote:
> this won't support the case where the app creates it own console after
> it has started
Duh! Forgot about that one. This is getting funny :) What about this one:
When we create a console, we start a process (say wconsole, since the
wineconso
"Dimitrie O. Paun" a écrit :
>
> On November 21, 2002 03:25 pm, Eric Pouech wrote:
> > > This seems complicated... :)
> >
> > that's why we need to simplify what we want to do ;-))
>
> :)
>
> > this won't work, because CreateProcess passes from parent to child some
> > context information th
On November 21, 2002 03:25 pm, Eric Pouech wrote:
> > This seems complicated... :)
>
> that's why we need to simplify what we want to do ;-))
:)
> this won't work, because CreateProcess passes from parent to child some
> context information the child get it from wineserver using its parent
>
> This seems complicated... :)
that's why we need to simplify what we want to do ;-))
> But, here's how I look at it:
>
> 1. If we start the program in our console, it makes use of it:
> xterm -e "wine myprog.exe"
> you say it should work just fine.
>
> 2. Now, in the case we s
On November 21, 2002 02:47 pm, Eric Pouech wrote:
> various stuff:
> - if another wine console is running on the same terminal
How can it, we're talking about the case when _we_ start up the
console, so there shouldn't be anything on it, no?
> - when a console is started, we have to wait until al
"Dimitrie O. Paun" a écrit :
>
> On November 21, 2002 02:26 pm, Eric Pouech wrote:
> > this won't be easily possible, because wine has no knowledge on what
> > currently exists on the terminal
>
> Sorry, I don't understand exactly the issues here, but what don't we
> know to exist? I mean, if we
On November 21, 2002 02:26 pm, Eric Pouech wrote:
> this won't be easily possible, because wine has no knowledge on what
> currently exists on the terminal
Sorry, I don't understand exactly the issues here, but what don't we
know to exist? I mean, if we start it, can't we assume a blank slate?
--
> Sure, that's the initial invocation. But beyond that, what if
> I run a a windows app, and that one starts a command line app?
> In that case, I don't want wineconsole to pop up, but rather
> my console of choice. A common example is winedbg: it starts up
> in wineconsole, but I'd rather have it
> 1. If I start a command-line app in a terminal, I want
> the app to make use of the terminal, not NOT start a
> new one. Unix apps behave like this (eg. Midnight Commander)
> and command-line Wine apps should not behave any differently.
that's the 2 => B case (or more exactly, th
On November 21, 2002 01:55 pm, Eric Pouech wrote:
> > 4. I would love to be able to choose the terminal that's started.
> > That is, instead of having wineconsole pop up, wouldn't it
> > be cool if konsole/gnome-terminal/rxvt/xterm/etc would be
> > fired up depending on desktop-env
> Grr. Maybe I should go look at last year's ttydrv to see how
> to do it properly :-)
most of the curses loading is protected by ifdef:s
(btw curses inclusion is 2 years and 8 months old... perhaps you didn't
have the curse-devel package installed by then)
did you try recompiling wine with --with
Marcus Meissner a écrit :
> Hmm, what is wrong with A for all the first 3 cases?
nothing. but we need a way to let users pick up 2 => B (it doesn't mean
we'll forbid 2 => A for all the wineconsole lovers ;-)
A+
Eric Pouech wrote:
Dan Kegel a écrit :
Eric wrote:
N2: one could try running wineconsole USER backend with ttydrv instead
of x11drv, but that's out of the scope of this (maybe for Dimi's fun
projects list
ttydrv is not as far out as all that. I use ttydrv now to
run commandline windows prog
On November 19, 2002 03:38 pm, Eric Pouech wrote:
> If you have any comments, speak up now !!
I will not comment directly on the solutions presented, but
rather I will try to list my requirements, as a user. Note
that some/all of them may be working already, but it's here
for as a reference:
1.
On Tue, Nov 19, 2002 at 09:38:02PM +0100, Eric Pouech wrote:
> I did send a couple of days ago a first patch about the (n)curses
> backend to wineconsole
> Alexandre commented a few implementation issues in it, which may change
> a bit what I started with and how the wineconsole should behave:
>
>
Eric Pouech <[EMAIL PROTECTED]> writes:
> the issue you're having right now is that:
> - wine, at startup, always create a specific task to handle the desktop
> (even just a CUI program is run, but you cannot tell in advance)
> - this requires gdi & user to be loaded
Note that this is only for 16
Dan Kegel a écrit :
>
> Eric wrote:
> > N2: one could try running wineconsole USER backend with ttydrv instead
> > of x11drv, but that's out of the scope of this (maybe for Dimi's fun
> > projects list
>
> ttydrv is not as far out as all that. I use ttydrv now to
> run commandline windows progra
Eric wrote:
N2: one could try running wineconsole USER backend with ttydrv instead
of x11drv, but that's out of the scope of this (maybe for Dimi's fun
projects list
ttydrv is not as far out as all that. I use ttydrv now to
run commandline windows programs that output to stdout.
I *cannot* use
I did send a couple of days ago a first patch about the (n)curses
backend to wineconsole
Alexandre commented a few implementation issues in it, which may change
a bit what I started with and how the wineconsole should behave:
console creation can be invoked from different contexts:
1/ the program
22 matches
Mail list logo
