Hi Ellen,
Can you specify some steps to reproduce the printing problem in Leopard (or upload a small sample) ? The issues related to 3.5 developer won’t be fixed anymore (so, for example, the Define Parts dialog ). Also, for other problems, I think your request is a bit vague. Can you point out the problems Servoy has in Leopard ?
Laurian
Resurrecting this problem. I’ve finally gotten it troubleshot down to a very specific symptom. This is CLIENT ONLY, 3.5.8. It appears that on Leopard, if you’re getting the Mac print dialog when sending the printout, it’ll work (meaning print everything that shows on the print preview Servoy provides). I say mac print dialog because it has many more functions – for sure has a “preview” button in the lower left, and looks designed for a mac via aqua, as opposed to what I’m guessing is the Java print dialog, which has no aqua and no preview button. I get the mac system print dialog on my Leopard laptop when using client launched from Servoy Developer’s internal http server. I do NOT get it in Client when i launch from my customer’s Servoy Server, even though I have set the server setting to use system print dialog, and saved that setting, and restarted the service.
Can we reopen this (hopefully) bug? I will post this in the Servoy Support System in the previous entry which was closed because it wasn’t reproducable. Hope this helps! Clearly its Java’s fault (since Tiger and Windows work) but if Servoy can help me make a workaround I won’t have so much anger at the new macs being installed every day around here.
ellenmeserow:
Resurrecting this problem. I’ve finally gotten it troubleshot down to a very specific symptom. This is CLIENT ONLY, 3.5.8. It appears that on Leopard, if you’re getting the Mac print dialog when sending the printout, it’ll work (meaning print everything that shows on the print preview Servoy provides). I say mac print dialog because it has many more functions – for sure has a “preview” button in the lower left, and looks designed for a mac via aqua, as opposed to what I’m guessing is the Java print dialog, which has no aqua and no preview button. I get the mac system print dialog on my Leopard laptop when using client launched from Servoy Developer’s internal http server. I do NOT get it in Client when i launch from my customer’s Servoy Server, even though I have set the server setting to use system print dialog, and saved that setting, and restarted the service.Can we reopen this (hopefully) bug? I will post this in the Servoy Support System in the previous entry which was closed because it wasn’t reproducable. Hope this helps! Clearly its Java’s fault (since Tiger and Windows work) but if Servoy can help me make a workaround I won’t have so much anger at the new macs being installed every day around here.
Sure, we’ll have a look at this issue.
Hoping for some advice on the best way to design a smartclient layout that looks great on all platforms, while waiting for Apple to do something about Java on OSX 10.5. OSX 10.4 is fine. Maybe we need to wait for Snow Leopard? This hurdle is a show stopper for me, not going beyond the development stage until I learn how to make it work well.
My main issues is with comboboxes and check boxes, on OSX 10.5
If you set LAF to Default, ComboBox on a Mac looks odd, left to right (contracted); and don’t fit top and bottom unless you make the field 22 px high; text is truncated compared to other LAFs.
Check boxes don’t look great either.
[attachment=1]Picture 43.png[/attachment]
If you change the LAF to anything else, it looks great, on Mac but the Comboboxes don’t work with a mouse, only keyboard.
[attachment=2]Picture 42.png[/attachment]
Is there a guide for best practice on this? Grateful to anyone who can post an example layout with style settings for these field types.
These are my default Java settings on OSX 10.5.7 on an iMac Intel Core 2 Duo, Servoy Developer 4.1.3,
[attachment=0]Picture 44.png[/attachment]
Hi Antonio,
From the looks of it you are using a custom border around your controls. The Mac OS X LAF doesn’t like that.
Perhaps you should checkout the “Designing for Hybrid Deployment” presentation I gave at ServoyWorld 2007. You can find the slides here.
Hope this helps.
Thanks Robert, There’s a lot of information on the forum, so much so it’s sometimes hard to find the good things there. Thanks for this gem.
You were right about the borders and transparency.
It did raise some more questions
Is it correct that the only way to get Comboboxes to work with mouse clicks on Leopard is with Default LAF? (Keyboard seems to work with any LAF). Is there ANY other LAF where combos work with the mouse?
Setting size of comboboxes to 22 px, not hard to do, but then it throws out the positioning of elements below, as far as the snap-to-grid feature, if they are packed in adjacent to each other.
BTW, on you slide 18 what are the top and bottom boxes in each pair?
The sequence of buttons was another irritation. Interested to read your workaround.
It’s still somewhat frustrating that we have to script so that buttons appear in the same sequence on all platforms. The global method you give works with forms. What about dialog boxes? I guess the way to fix the order is
if (application.getOSName() != 'Mac OS X')
{
plugins.dialogs.showQuestionDialog("Test of Buttons","Test the sequence of buttons","Yes","No","Cancel")
}
else
{
plugins.dialogs.showQuestionDialog("Test of Buttons","Test the sequence of buttons","Cancel","No","Yes")
}
or perhaps another workaround global method that takes a list of arguments and puts them in the correct order.
(Didn’t we escape from FMP because of all the workarounds? )
I was really happy with Metal and Kunststoff before Leopard came along.
Oh, the width of Comboboxes on Mac Default are 5 px narrower on each side.
Another script needed to move them 5 px to the left and make them 10 wider?
ellenmeserow:
Resurrecting this problem. I’ve finally gotten it troubleshot down to a very specific symptom. This is CLIENT ONLY, 3.5.8. It appears that on Leopard, if you’re getting the Mac print dialog when sending the printout, it’ll work (meaning print everything that shows on the print preview Servoy provides). I say mac print dialog because it has many more functions – for sure has a “preview” button in the lower left, and looks designed for a mac via aqua, as opposed to what I’m guessing is the Java print dialog, which has no aqua and no preview button. I get the mac system print dialog on my Leopard laptop when using client launched from Servoy Developer’s internal http server. I do NOT get it in Client when i launch from my customer’s Servoy Server, even though I have set the server setting to use system print dialog, and saved that setting, and restarted the service.Can we reopen this (hopefully) bug? I will post this in the Servoy Support System in the previous entry which was closed because it wasn’t reproducable. Hope this helps! Clearly its Java’s fault (since Tiger and Windows work) but if Servoy can help me make a workaround I won’t have so much anger at the new macs being installed every day around here.
The printing issues on Mac were caused by having useSystemPrintDialog = false for Mac client. There are some Mac issues with implementation in this case. If useSystemPrintDialog was set to true everything worked well .
antonio:
- Is it correct that the only way to get Comboboxes to work with mouse clicks on Leopard is with Default LAF? (Keyboard seems to work with any LAF). Is there ANY other LAF where combos work with the mouse?
I did some quick tests in Servoy 3.5.10 and I don’t think the combos in other LAF’s work correctly with Leopard. Seems you are stuck with the default (Mac OS X) LAF.
antonio:
2. Setting size of comboboxes to 22 px, not hard to do, but then it throws out the positioning of elements below, as far as the snap-to-grid feature, if they are packed in adjacent to each other.
Snap it to grid, change the height from 20 to 22 and move them one pixel up so they align nicely with the rest that are 20 pixels high.
antonio:
BTW, on you slide 18 what are the top and bottom boxes in each pair?
The first combo is one where the Editable property is set to true and the next one Editable is set to false. That slide shows that using a height of 20 pixels clip the controls at the top and bottom. 21 pixels clips only the non-editable combo and 22 pixels makes it look all right.
Just to be clear, a ‘non-editable’ combo is still editable in the sense that you can select a value, but you can’t type anything in.
antonio:
3. The sequence of buttons was another irritation. Interested to read your workaround.
It’s still somewhat frustrating that we have to script so that buttons appear in the same sequence on all platforms. The global method you give works with forms. What about dialog boxes? I guess the way to fix the order isif (application.getOSName() != 'Mac OS X')
{
plugins.dialogs.showQuestionDialog(“Test of Buttons”,“Test the sequence of buttons”,“Yes”,“No”,“Cancel”)
}
else
{
plugins.dialogs.showQuestionDialog(“Test of Buttons”,“Test the sequence of buttons”,“Cancel”,“No”,“Yes”)
}
This code does solve your sequence issue but create another one. The dialog plugin makes the first defined button the default one. So on any platform other than Mac OS X the YES button is the default. Which is in most cases NOT what you want.
Perhaps a nice case for a feature request.
antonio:
4. Anything we can do with the position of the Tabs on tabpanels? Or are we stuck having them in the middle on OSX with default LAF?
I don’t think you can’t even change that when you develop in Cocoa unless you custom code this. It’s how the Mac OS X tabpanel works.
If you don’t like it (like me) then you roll your own tabs.
Use a tabpanel with hidden tabs and place your own tabs (images/buttons/whatever) in the place you want to. Simple put a method on it that sets the tabindex to the number of the tab. Easy and 100% cross-platform (including Web).
antonio:
Oh, the width of Comboboxes on Mac Default are 5 px narrower on each side.
Another script needed to move them 5 px to the left and make them 10 wider?
That’s how Apple wants it (apperantly). Same kind of issue with tabpanels, your forms have a lot less space in there.
As per slide 28 in my preso:
“When you design for Mac OS X then, in general, you are fine with Windows/Linux”
Hope this helps.
Thanks for all the excellent tips, and documenting them in one place.
Much appreciated.