On 5 Sep 2012, at 21:13, Chris Russ wrote:
> I have 177 plug-ins in one product line and 22 in another. Both would need
> to be split in this fashion. And of course, the Mac side "Just Works."
>
> You can probably guess why I'm less than thrilled.
OK, I can see how that *might* be a pain.
On 5 Sep 2012, at 21:13, Gonzalo Garramuno wrote:
> On my Linux box (Kubuntu), doing a fullscreen and turning it off does not
> create the window's decorations back again. The problem is not there on
> Win32 or Win64. The problem appears in all versions of fltk (although I am
> interested in
On 09/05/12 13:13, Gonzalo Garramuno wrote:
> On my Linux box (Kubuntu), doing a fullscreen and turning it off does not
> create the window's decorations back again. The problem is not there on
> Win32 or Win64. The problem appears in all versions of fltk (although I am
> interested in fltk2).
On 09/05/12 13:20, Greg Ercolano wrote:
> On 09/05/12 13:13, Gonzalo Garramuno wrote:
>> On my Linux box (Kubuntu), doing a fullscreen and turning it off does not
>> create the window's decorations back again. The problem is not there on
>> Win32 or Win64. The problem appears in all versions of
I have 177 plug-ins in one product line and 22 in another. Both would need to
be split in this fashion. And of course, the Mac side "Just Works."
You can probably guess why I'm less than thrilled.
I'm going to use a set of Memory-Mapped files to send the material
back-and-forth. We'll see if
On my Linux box (Kubuntu), doing a fullscreen and turning it off does not
create the window's decorations back again. The problem is not there on Win32
or Win64. The problem appears in all versions of fltk (although I am
interested in fltk2).
It seems FLTK is not playing nicely with the window
On 05.09.2012, at 18:25, "MacArthur, Ian (SELEX GALILEO, UK)"
wrote:
>> Ah, I see what you mean. The beauty of NewtonOS is, that there is almost
>> no app out there that uses native code. All existing apps are compiled
>> into NewtonOS byte code which can we already compile and run. So it is
>>
Le 05/09/2012 10:23, MacArthur, Ian (SELEX GALILEO, UK) a écrit :
I will try to look for alternative implementation.
> A second thought...
>
> What stuyle do you want to apply to the drop-down section? A gradient as you
> have done in the menu bar (and whick looks nice BTW) or just plain?
>
> Te
On 09/05/12 10:14, Greg Ercolano wrote:
>> Also, I have absolutely no objections to contributing to the cause.
>> I'm pretty sure that someone else should be testing and checking
>> in any changes that are worthwhile keeping, though. :)
Oh, and I meant to reply to this in my previous post;
On 09/05/12 07:31, Chris Russ wrote:
> I've gotten approval from the bosses to attempt a two-part plug-in -- first
> part
> that grabs the image, second part that does the processing/UI. Now I have to
> do it.
> Doing it as a DLL is no biggie -- I've got a lot of experience with that,
> but maki
> Ah, I see what you mean. The beauty of NewtonOS is, that there is almost
> no app out there that uses native code. All existing apps are compiled
> into NewtonOS byte code which can we already compile and run. So it is
> actually a bit less work because in the end we need "only" the modern API.
> I've gotten approval from the bosses to attempt a two-part plug-in --
> first part that grabs the image, second part that does the processing/UI.
> Now I have to do it. Doing it as a DLL is no biggie -- I've got a lot of
> experience with that, but making part be stand-alone in a different
> pro
Matthais,
Actually, this is what Adobe does in DllMain (you'll laugh):
extern "C" BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call,
LPVOID);
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID)
{
dllInstance = static_cast(hModule);
return true;
}
On 05.09.2012, at 15:21, "MacArthur, Ian (SELEX GALILEO, UK)"
wrote:
>
>>> Though... IIRC the Newton ROM presented some API in C++ (or ObjC?) based
>> on the calling convention of some obscure obsolete compiler... so creating
>> code to the same ABI might be, um, "tricky"...?
>
>
>> Yes, it
Guys,
Looks like you have most of the details right.
Here's what I did for static re-initialization. (Figure 1A & 1B) Certainly I
must have missed some things. For one, I'm not especially thrilled with how I
hacked Fl_Surface_Device and Fl_Display_Device with set() functions, not how
the Fl_
> > Though... IIRC the Newton ROM presented some API in C++ (or ObjC?) based
> on the calling convention of some obscure obsolete compiler... so creating
> code to the same ABI might be, um, "tricky"...?
> Yes, it is tricky. I need interfaces between the Just In TIme compiler and
> the native co
Chris et al,
Can I just summarise what I *think* is being done here, to make sure I actually
understand the question?
So...
- I imagine that PS calls a function with a C API (and perhaps provides e.g.
callbacks, also with C API, to allow the called function to interact with the
PS instance.)
On 05.09.2012, at 11:28, "MacArthur, Ian (SELEX GALILEO, UK)"
wrote:
>
>>> I wonder if we need to explicitly unregister the fltk window classes
>> from the Windows context and then re-assert them, or maybe register them
>> with a different name each time, or something...?
>>
>>
>> I am not s
On 05.09.2012, at 11:03, "MacArthur, Ian (SELEX GALILEO, UK)"
wrote:
>
>> Sorry, I clicked the worng address field. This was of course supposed to
>> go to the Einstein Newton emulator group. ;-)
>
> Though there are folk here too who would like to see a "native"
> Einstein/Newton...
>
> Th
> > I wonder if we need to explicitly unregister the fltk window classes
> from the Windows context and then re-assert them, or maybe register them
> with a different name each time, or something...?
>
>
> I am not sure if the entire endeavor will ever work. It's a long time ago
> that I used th
On 05.09.2012, at 10:37, "MacArthur, Ian (SELEX GALILEO, UK)"
wrote:
>
>> FLTKInstance = GetModuleHandle("fltkdll.dll"); //access count is N
>> (assumed > 0)
>> while (FLTKInstance)
>> {
>> BOOL fi = FreeLibrary(FLTKInstance);
>> if (fi) FLTKInstance =
> Sorry, I clicked the worng address field. This was of course supposed to
> go to the Einstein Newton emulator group. ;-)
Though there are folk here too who would like to see a "native"
Einstein/Newton...
That said, I doubt I can help - I can't get on with Xcode at all, still have
3.2.6, and
Sorry, I clicked the worng address field. This was of course supposed to go to
the Einstein Newton emulator group. ;-)
On 05.09.2012, at 10:54, Matthias Melcher wrote:
>
> This drives me nuts!
>
> I just had the one Eureka moment I was waiting for: how to move Einstein from
> being an Emula
This drives me nuts!
I just had the one Eureka moment I was waiting for: how to move Einstein from
being an Emulator (slow, interpreting the ROM, inflexible) piece by piece to
become a simulator (running native code at full speed, rebuilding the OS, being
copyright free).
And then this: using
> FLTKInstance = GetModuleHandle("fltkdll.dll"); //access count is N
> (assumed > 0)
> while (FLTKInstance)
> {
> BOOL fi = FreeLibrary(FLTKInstance);
> if (fi) FLTKInstance = GetModuleHandle("fltkdll.dll");
> elseFLTKInstance = NULL
> I'm only allowed to hit Photoshop callbacks from within the thread that
> Photoshop calls me with.
I don't have the PS SDK, so can't play along at home... In consequence,
anything I say is likely to be bogus or at best misleading - be advised!
> In the past, I've used pure Win32 calls under
> I successfully draw a gradient box for the main menu bar using a
> subclass of Fl_Menu_Bar (http://hylvenir.free.fr/fltk/menu.png)
> using a no box.
>
> But, is there a way to access the dropdown box draw method of the
> Fl_Menu_Item, quickly I don't find anything ?
A second thought...
What
> I successfully draw a gradient box for the main menu bar using a
> subclass of Fl_Menu_Bar (http://hylvenir.free.fr/fltk/menu.png)
> using a no box.
>
> But, is there a way to access the dropdown box draw method of the
> Fl_Menu_Item, quickly I don't find anything ?
Not that I am aware of - th
28 matches
Mail list logo
