tcl-mac — Q&A for Tcl on the Macintosh platform

Re: [MACTCL] App Store question

[Adrian R. <adr...@gm...>]

Hi,

If the app itself is on the app store they would just need an iTunes account, not iTunesConnect.

If you don't want to put the app on the app store but you have a developer / iTunesConnect account, and ASSUMING it works the same was as iOS, then:  you can use "ad hoc" distribution, and add the device IDs from customer's machines to the provisioning profile.

Another approach if neither of these are good might be to separate the app and the configuration data completely, and have the customers download the config data separately from the app (which just comes with a generic default).


-Adrian


On Apr 15, 2013, at 1:13 PM, David Zolli <kr...@kr...> wrote:

> Hi all,
> 
> My question is a bit off topic but I don't find the answer so I try everywhere.
> 
> I'ld like to know if you know how to easily share on Apple App Store an app you've made for a customer.
> 
> By 'easily' I mean without asking my customers to set up accounts in iTunes Connect.
> 
> I need this because:
> 
>   - these applications are free of charge in App Store
>   - it's always the same app with different company logos and colors (and loading different XML data, of course)
>   - my customers know nothing about app development and most of them even don't speak english (so it's pretty hard to make them register in iTunes Connect).
> 
> Of course, I'm looking for a legal solution approved by Apple. ;)
> 
> Thanks for your help and please forgive me for this little OT question.
> 
> -- 
> David Zolli
> kr...@kr...
> http://www.kroc.tk
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] App Store question

[David Z. <kr...@kr...>]

Hi all,

My question is a bit off topic but I don't find the answer so I try everywhere.

I'ld like to know if you know how to easily share on Apple App Store an app you've made for a customer.

By 'easily' I mean without asking my customers to set up accounts in iTunes Connect.

I need this because:

   - these applications are free of charge in App Store
   - it's always the same app with different company logos and colors (and loading different XML data, of course)
   - my customers know nothing about app development and most of them even don't speak english (so it's pretty hard to make them register in iTunes Connect).

Of course, I'm looking for a legal solution approved by Apple. ;)

Thanks for your help and please forgive me for this little OT question.

-- 
David Zolli
kr...@kr...
http://www.kroc.tk

[MACTCL] 2nd Call For Papers, 20th Annual Tcl/Tk Conference 2013

[Andreas K. <and...@ac...>]

[[ Notes:

   Karl Lehenbauer of FlightAware is confirmed as our Keynote speaker.
   http://www.flightaware.com

]]

20'th Annual Tcl/Tk Conference (Tcl'2013)
http://www.tcl.tk/community/tcl2013/

September 23 - 27, 2013
Bourbon Orleans Hotel
New Orleans, Louisiana, USA
http://www.bourbonorleans.com/

Important Dates:

Abstracts and proposals due   June      22, 2013
Notification to authors       August     5, 2013
Author materials due          September  2, 2013
Tutorials Start               September 23, 2013
Conference starts             September 25, 2013

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2013 will be held in New Orleans, Louisiana, USA from September
23 - 27, 2013. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2013. Authors of accepted abstracts will have until September 2, 2013
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 5, 2013. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 3, 2013. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2013/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp			General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.	Program Chair
Gerald Lester           KnG Consulting, LLC		Site/Facilities Chair
Arjen Markus            Deltares
Brian Griffin           Mentor Graphics
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB Michigan State University
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2013 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

Re: [MACTCL] Retina display

[Jeff H. <je...@ac...>]

On 2013-03-21, at 6:33 AM, Kevin Walzer <kw...@co...> wrote:

> On 3/19/13 11:18 AM, Jeff Hobbs wrote:
>> 
>> FWIW I have an rMBP and Tk does look somewhat pixelated.  I suppose the
>> icons might also be pixelated, but you don't notice it as much.  I've
>> attached a TDK screenshot where you can see some of this.
> 
> The text can be made Retina-friendly with a new key in the app's Info.plist file:
> 
> <key>NSHighResolutionCapable</key>
> <true/>
> 
> CoreText provides the HiDPI hooks out of the box.

I've seen that trick, but it does not work on TDK apps from my experience (which have an Info.plit for tclapp.app, but also call out to tdkbase.app).  I've modified both to no avail, even forcing the rebuild of the Info.plist cache (via renaming).

> A related technical question: my theory that the tk::mac::iconBitmap command is the way to go is untested, but it provides direct access to the NSImage API's that are in effect here. Standard Tk images do not. However, I noticed that TkImg at some point added support for multi-file TIF images in a single file--does anyone have experience with that?

Not me.

Jeff

Re: [MACTCL] Retina display

[Kevin W. <kw...@co...>]

On 3/19/13 11:18 AM, Jeff Hobbs wrote:
>
> FWIW I have an rMBP and Tk does look somewhat pixelated.  I suppose the
> icons might also be pixelated, but you don't notice it as much.  I've
> attached a TDK screenshot where you can see some of this.

The text can be made Retina-friendly with a new key in the app's 
Info.plist file:

<key>NSHighResolutionCapable</key>
<true/>

CoreText provides the HiDPI hooks out of the box.

The other trick mentioned on-list, from SO, doesn't seem to work if 
you're on Lion. Bummer.

When I get the app I'm working on a bit further along, I may post a 
request for testing from someone with a Retina Mac. My interest here is 
documenting best practices for Tk apps in this brave new world, and I 
will do so.

A related technical question: my theory that the tk::mac::iconBitmap 
command is the way to go is untested, but it provides direct access to 
the NSImage API's that are in effect here. Standard Tk images do not. 
However, I noticed that TkImg at some point added support for multi-file 
TIF images in a single file--does anyone have experience with that?

--Kevin


-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Re: [MACTCL] Retina display

[Jeff H. <je...@ac...>]

On 2013-03-19, at 6:51 AM, Kevin Walzer <kw...@co...> wrote:

> Anyone running, or developing, their Tk apps with a HiDPI screen (Retina 
> display)? I'm beginning to update my apps with an eye toward the Retina 
> display, but I don't have the hardware (nor any way to emulate on my 
> current setup). I'm especially interested in knowing what effect the 
> Retina display has on things like images on buttons and labels. I have a 
> few ideas on how to make images play nice in Tk in Retina displays (the 
> ::tk::mac::iconBitmap command provides the necessary hooks into NSImage, 
> I believe), but I'd like to see what others are running into.

FWIW I have an rMBP and Tk does look somewhat pixelated.  I suppose the icons might also be pixelated, but you don't notice it as much.  I've attached a TDK screenshot where you can see some of this.

Jeff

Re: [MACTCL] Retina display

[Wojciech K. <woj...@ko...>]

>From what I know you can emulate HiDPI displays in a regular Mac:

http://stackoverflow.com/questions/12124576/how-to-simulate-a-retina-display-hidpi-mode-in-mac-os-x-10-8-mountain-lion-on

Not sure if you first need to update to 10.8, though.

2013/3/19 Kevin Walzer <kw...@co...>:
> Anyone running, or developing, their Tk apps with a HiDPI screen (Retina
> display)? I'm beginning to update my apps with an eye toward the Retina
> display, but I don't have the hardware (nor any way to emulate on my
> current setup). I'm especially interested in knowing what effect the
> Retina display has on things like images on buttons and labels. I have a
> few ideas on how to make images play nice in Tk in Retina displays (the
> ::tk::mac::iconBitmap command provides the necessary hooks into NSImage,
> I believe), but I'd like to see what others are running into.
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Retina display

[Kevin W. <kw...@co...>]

Anyone running, or developing, their Tk apps with a HiDPI screen (Retina 
display)? I'm beginning to update my apps with an eye toward the Retina 
display, but I don't have the hardware (nor any way to emulate on my 
current setup). I'm especially interested in knowing what effect the 
Retina display has on things like images on buttons and labels. I have a 
few ideas on how to make images play nice in Tk in Retina displays (the 
::tk::mac::iconBitmap command provides the necessary hooks into NSImage, 
I believe), but I'd like to see what others are running into.

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Re: [MACTCL] add entry to .menubar.apple

[Kevin W. <kw...@co...>]

On 3/6/13 4:09 AM, Zbigniew Diaczyszyn wrote:
>
>
> Am 05.03.2013 23:34, schrieb Kevin Walzer:
>> On 3/5/13 3:26 PM, Zbigniew Diaczyszyn wrote:
>>>
>>> Unfortunately it does not work, at least with ActiveState's basekit
>>> 8.5.13.
>>
>> Which part doesn't work--adding it or adding it after the preferences
>> menu item?
>
>   menu .mb.apple
>   .mb.apple add command -label "About " -command tkAboutDialog
>   .mb.apple add command -label "Check " -command checkUpdate
>   .mb.apple add separator
>   .mb add cascade -label "Test" -menu .mb.apple
>
> Sourcing the code or packing it as an tclkit executable will show a main
> menu line with a cascade entry "Test" after "Help" offering the cascade
> with "About" and "Check".
>
>

Based on your description, I think you're not doing something right 
here, but it's hard to tell because we don't have the complete menu 
code. There should be no additional menu items after "help."

It's a tricky practice  to get the Apple menu right; it has to be set up 
early, and then the menubar has to be configured as the main one as the 
very last command of menu setup. Here's my complete menu code from the 
app I discussed:

     menu .mb.apple
     .mb.apple add command -label "About FileMorph" -command tkAboutDialog
     .mb.apple add command -label "Check for Updates" -command checkUpdate
     .mb.apple add separator
     .mb add cascade -label "FileMorph" -menu .mb.apple


     menu .mb.search -tearoff -0
     .mb.search add command -label "Select Directory" -command setDir
     .mb.search add command -label "Select File" -command setFile
     .mb add cascade -label "Directory" -menu .mb.search

     #window menu
     windowlist::windowMenu .mb


     menu .mb.help -tearoff 0
     if {[tk windowingsystem] eq "aqua"} {
	.mb.help add command -label "Contact Code by Kevin" -command [list 
machelp::usermail $cachedir/stdout.txt $cachedir/stderr.txt]
	.mb.help add command -label "Web Site" -command [list machelp::appweb 
$cachedir/stdout.txt $cachedir/stderr.txt]
	if {$regproc::appstore == 0} {
	    .mb.help add command -label "License" -command regproc::getReg
	    .mb.help add command -label "Check for Updates" -command [list 
softwareupdate::checkVersion $appname::name $appname::version]
	}
     }
     .mb add cascade -label "Help" -menu .mb.help

     . configure -menu .mb



Hope this helps,
Kevin


-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Re: [MACTCL] add entry to .menubar.apple

[Peter C. <pe...@ca...>]

Hi Zbigniew,

A quick look at a selection of other apps shows they all have their 
About and/or Check For Updates above Preferences in the Apple menu:

  - Mozilla Thunderbird and Firefox,
  - Google Chrome,
  - Videolan VLC,
  - Chicken of the VNC,
  - Apple's Safari,
  - Apple's iMovie.

If there was ever such an expectation from users, they've been 
disappointed by all of the big players.

The odd one out was VMware Fusion, which just goes to show that 
nothing's carved in stone.

For what it's worth, I use the order: About, Check For Updates, 
Preferences. Never had any complaints :)


Pete.

> On 3/5/13 3:26 PM, Zbigniew Diaczyszyn wrote:
>> A friend told me that OSX users expect the Update entry right under
>> Preferences but perhaps it is just a question of taste where to place
>> this menu entry.

Re: [MACTCL] add entry to .menubar.apple

[Kevin W. <kw...@co...>]

On 3/5/13 3:26 PM, Zbigniew Diaczyszyn wrote:
>
> Unfortunately it does not work, at least with ActiveState's basekit 8.5.13.

Which part doesn't work--adding it or adding it after the preferences 
menu item?
>
>
> A friend told me that OSX users expect the Update entry right under
> Preferences but perhaps it is just a question of taste where to place
> this menu entry.
>

As I said before, Tk doesn't provide hooks to add stuff under the 
preferences menu--that real estate is owned by the system. You can add 
things above it. Many apps (including one I'm working on) add the "check 
for update" below the app menu item ("About this App) and before the 
preferences item.

You can also put things under the help menu, of course--that's another, 
though less standard, place to put the "update" item. (My apps currently 
put it there but I'm moving it.)

--Kevin


-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Re: [MACTCL] add entry to .menubar.apple

[Kevin W. <kw...@co...>]

On 3/5/13 2:15 AM, Zbigniew Diaczyszyn wrote:
> Is there a Tk way to post an additional entry into the application's menu?
>
> I would like to have an entry "Check for Update" after the Preferences
> entry.
>
> .mbar.apple add command -label "Check for Update" -command bell
>
> or
>
> .mbar.apple insert 2 command -label "Check for Update" -command bell
>
> fails.


I don't think it can be added after the "preferences" item--that stuff 
is hard-coded by Apple. But you can add it before:

     menu .mb.apple
     .mb.apple add command -label "About FileMorph" -command tkAboutDialog
     .mb.apple add command -label "Check for Updates" -command checkUpdate
     .mb.apple add separator
     .mb add cascade -label "FileMorph" -menu .mb.apple



-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[MACTCL] add entry to .menubar.apple

[Zbigniew D. <z....@gm...>]

Is there a Tk way to post an additional entry into the application's menu?

I would like to have an entry "Check for Update" after the Preferences 
entry.

.mbar.apple add command -label "Check for Update" -command bell

or

.mbar.apple insert 2 command -label "Check for Update" -command bell

fails.

[MACTCL] 1st Call For Papers, 19th Annual Tcl/Tk Conference 2012

[Andreas K. <and...@ac...>]

20'th Annual Tcl/Tk Conference (Tcl'2013)
http://www.tcl.tk/community/tcl2013/

September 23 - 27, 2013
Bourbon Orleans Hotel
New Orleans, Louisiana, USA

Important Dates:

Abstracts and proposals due   June      22, 2013
Notification to authors       August     5, 2013
Author materials due          September  2, 2013
Tutorials Start               September 23, 2013
Conference starts             September 25, 2013

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2013 will be held in New Orleans, Louisiana, USA from September
23 - 27, 2013. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2013. Authors of accepted abstracts will have until September 2, 2013
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 5, 2013. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 3, 2013. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2013/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp			General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.	Program Chair
Gerald Lester           KnG Consulting, LLC		Site/Facilities Chair
Arjen Markus            Deltares
Brian Griffin           Mentor Graphics
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB Michigan State University
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2013 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

[MACTCL] SPAM

[Steven <ste...@ya...>]

Please don't click on previous link. It is a spam/mailman vulnerability
Sorry :(

[MACTCL] hi

[Steven <ste...@ya...>]

almost cannot believe it..what do you think http://bit.ly/124X7QV

Steven

[MACTCL] Quick note on current projects

[Kevin W. <kw...@co...>]

Hi all,

Just a quick note about a couple of extension packages I'm working on: 
not quite yet ready for release, but making excellent progress and I'll 
have them ready soon.

1. Native Tcl wrapper for Growl. I'm using a very nice library called 
gntp-send, at https://github.com/mattn/gntp-send, which implements the 
new GNTP protocl that powers recent versions of Growl on OS X (the 
versions available in the Mac App Store). I'm using SWIG to generate the 
Tcl bindings, and it's going very smoothly. Still to be determined is 
how compatible I make this version with previous Tcl wrappers of Growl. 
Suggestions, if any, are welcome. What is important is that this new 
version of the Tcl Growl wrapper would be compatible with the Mac App 
Store's sandbox restrictions, as it does not require AppleScript or 
special sandbox exceptions.

2. Lion-style fullscreen support, with the button on the right-hand side 
of the window that smoothly animates the window to fullscreen 
proportions. I'm implementing this as an extension package because I 
found too much difficulty in integrating it with the [wm attributes $w 
-fullscreen 1] command in the core; also, Adrian Robert's recent patch 
makes that particular function work perfectly. This package will be 
separate and won't involve wm commands, it will simply put the button on 
the top of the window and let users make them fullscreen if they want.

These have been long-standing itches of mine, but with the recent push 
to fix bugs, integrate Cocoa into 8.5, and get 8.6 out the door, they 
have fallen to the back burner. Now it's time to move forward with them, 
along with one or two other projects.

More news when they're ready for release.

Best,
Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] [TCLCORE] wish8.6 X11 wrong path

[Alexander S. <a.s...@gm...>]

The workaround is only because there is a wrong path for loading Tk while app init.

I build Tcl and Tk 8.5.9 and 8.5.12 (Aqua and X11 with framework) on 10.6.x to 10.8.x and it works without problems.
The 8.6.0 build works also in coexistence on Mac OS X. Today we made a lot of Testing. All tests and tclets are working.
Just call a script with wish8.6 or wish8.6-X11 - done.

Only if you build Tk C packages you have to choose the correct "tkConfig.sh" and in package require you have to check
the "tk windowingsystem" aqua or x11 and load the correct library.

There is only a wrong Tk library path since 8.6.0, the library path in 8.5.x (framework build) is correct.

actual wrong path is:
  {/Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6/lib/Tk}
correct would be:
  {/Library/Frameworks/Tk.framework/Versions/8.6-X11/Tk}

I didn't find it in the config...


Regards,
Alex


Am 14.01.2013 um 15:31 schrieb Kevin Walzer <kw...@co...>:

> On 1/14/13 7:25 AM, Alexander Schöpe wrote:
>> 
>> After the following workaround "wish8.6-X11" starts without error:
>> 
>>  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:
>>  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr
>>  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6
>>  ln -s /Library/Frameworks/Tk.framework/Versions/8.6-X11 lib
> 
> When I build an X11-based wish on OS X, I don't try a framework build--I 
> just run the normal configure, make, make install from the Unix subdir 
> in the source tree. I wonder if some of the problems you're having are 
> the result of this. It doesn't seem technically impossible to run X11 
> Wish from a framework, but it seems to me that you are going against the 
> grain and doing it the hard way for no discernible purpose.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

--
Alexander Schöpe
Im Haarmannsbusch 125a
44797 Bochum

[MACTCL] wish8.6 X11 wrong path

[Alexander S. <a.s...@gm...>]

Hello Core-Team,

I build "wish8.6-X11" under Mac OS X 10.8.2 with XQuartz 2.7.4 installed.

Calling "wish8.6-X11" throws the following error:

 dyld: Library not loaded: /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6/lib/Tk
   Referenced from: /Users/alex/usr/local/bin/./wish-X11
   Reason: image not found
 Trace/BPT trap: 5


After the following workaround "wish8.6-X11" starts without error:

 mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:
 mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr
 mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6
 ln -s /Library/Frameworks/Tk.framework/Versions/8.6-X11 lib


This looks like "wish8.6-X11" try to load "Tk" dylib
as {/Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6/lib/Tk}
instead of {/Library/Frameworks/Tk.framework/Versions/8.6-X11/Tk}

I couldn't find where this wrong library path is build in the configure process.
Hope someone of the core-team could answer this question.

My settings are:

Darwin asmbp 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 16:32:48 PDT 2012; root:xnu-2050.20.9~2/RELEASE_X86_64 x86_64

export MACOSX_DEPLOYMENT_TARGET=10.5
export CFLAGS="-arch x86_64 -mmacosx-version-min=10.5"
export ver=8.6.0

make -C tcl${ver}/macosx install-deploy INSTALL_ROOT="${HOME}/" NATIVE_TCLSH="${HOME}/usr/local/bin/tclsh8.6" 2>&1 | tee log_make_tcl.txt

TK_X11=1 make -C tk${ver}/macosx install-deploy INSTALL_ROOT="${HOME}/" 2>&1  | tee log_make_tk_x11.txt

Regards,
Alex

[MACTCL] wish8.6 X11 wrong path

[Alexander S. <a.s...@gm...>]

Hello Core-Team,

I build "wish8.6-X11" under Mac OS X 10.8.2 with XQuartz 2.7.4 installed.

Calling "wish8.6-X11" throws the following error:

  dyld: Library not loaded: /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6/lib/Tk
    Referenced from: /Users/alex/usr/local/bin/./wish-X11
    Reason: image not found
  Trace/BPT trap: 5


After the following workaround "wish8.6-X11" starts without error:

  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:
  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr
  mkdir /Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6
  ln -s /Library/Frameworks/Tk.framework/Versions/8.6-X11 lib


This looks like "wish8.6-X11" try to load "Tk" dylib
as {/Library/Frameworks/Tk.framework/Versions/8.6-X11:/usr/X11R6/lib/Tk}
instead of {/Library/Frameworks/Tk.framework/Versions/8.6-X11/Tk}

I couldn't find where this wrong library path is build in the configure process.
Hope someone of the core-team could answer this question.

My settings are:

Darwin asmbp 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 16:32:48 PDT 2012; root:xnu-2050.20.9~2/RELEASE_X86_64 x86_64

export MACOSX_DEPLOYMENT_TARGET=10.5
export CFLAGS="-arch x86_64 -mmacosx-version-min=10.5"
export ver=8.6.0

make -C tcl${ver}/macosx install-deploy INSTALL_ROOT="${HOME}/" NATIVE_TCLSH="${HOME}/usr/local/bin/tclsh8.6" 2>&1 | tee log_make_tcl.txt

TK_X11=1 make -C tk${ver}/macosx install-deploy INSTALL_ROOT="${HOME}/" 2>&1  | tee log_make_tk_x11.txt

Regards,
Alex

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

[Revar D. <rev...@gm...>]

On Nov 29, 2012, at 11:54 AM, "Russell E. Owen" <ro...@uw...> wrote:

> In article <50B...@co...>,
> Kevin Walzer <kw...@co...> wrote:
> 
>> Unix:
>> 
>>    avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
>>     .....
>>    width = mbPtr->width * avgWidth;
>> 
>> Aqua/Cocoa:
>> 
>>        int avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
>>        width = mbPtr->width * avgWidth;
>> 
>> According to Russell, these similar implementations produce very 
>> different outcomes on the different platforms. The reason for this, I 
>> believe, is the difference between font rendering engines on the two 
>> platforms. His suggested fix, under Aqua, is to increment the width by 
>> some specified amount, which, I'm inferring, would make the Aqua 
>> implementation look more like the X11/Unix implementation visually. 
>> (Haven't tested it.)
> 
> Is is possible that the width (in pixels) on unix applies to the text 
> region of the widget, whereas on MacOS X the width in pixels applies to 
> the whole widget (including the checkbox for a checkbutton, the menu 
> indicator for a menubutton, etc.)?
> 

As I (vaguely) recall from my attempts several years ago, to make Tk Carbon (NOT Coacoa) look more native,  one problem is that buttons have big rounded endcaps that clip the viewable label text. Yet the measurement of width didn't refer to the label area, it referred to the entire width of the button.  So if you specified a button with 2 chars width, it wouldn't actually show it's label, as the endcaps would be taking up all the space.

My solution at the time, as I recall, was to add the endcap widths to the calculated button width.  That way if you set a button with width 4, it would display about 4 characters in it's label area.

[MACTCL] GCI tasks for Tcl/Tk

[Christopher S. M. <br...@ma...>]

Hello all,

BRL-CAD is participating in Google Code-In and we're getting a *lot* of students working on various tasks.  As Tcl/Tk is one of our bigger dependencies and we like to help out where we can, are there any sets of small tasks that would be beneficial to folks here?

I posed this question on IRC and didn't make too much headway, so I figured a wider audience might have some ideas.  These tasks are supposed to be brief (couple hours) and geared towards knowledgeable but inexperienced students.  They don't have to be just code, but can be (very isolated) bug hunting, testing, compiling, writing tutorials, reproducing/isolating issues,... anything really.  Here are some examples of things we've had them doing for us already:

http://www.google-melange.com/gci/task/view/google/gci2012/7975238
http://www.google-melange.com/gci/task/view/google/gci2012/7957220
http://www.google-melange.com/gci/task/view/google/gci2012/7950213
http://www.google-melange.com/gci/task/view/google/gci2012/7948214

The students have actually been surprisingly productive, capable, and with seemingly endless time (they're completing tasks about as fast as we can add them).  I know it's a scope stretch, but getting AquaTk is one of our biggest issues on the Mac platform so let us know if there's anything we can have them do to help sort out problems or make progress.

All I'd need from you is a brief write-up like in those examples of what the problem is that is simple enough for anyone to understand and specific instructions on what they need to do.  Any ideas?

Cheers!
Sean

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

[Russell E. O. <ro...@uw...>]

In article <50B...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> On 11/28/12 4:20 PM, Adrian Robert wrote:
> > I think if it's possible for Tk to support a widget option consistently 
> > across platforms it should do its best to do so.  What is or isn't best 
> > programming practice is one thing, but the API is kind of like a contract, 
> > that allows cross-platform applications to be written without the need for 
> > a lot of if-then's to handle different environments.
> 
> I certainly agree with this in principle. And, indeed, the internal 
> implementation of calculating menubutton width is very similar on both 
> Unix and Aqua (didn't check Windows):
> 
> Unix:
> 
> 	avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
>      .....
> 	width = mbPtr->width * avgWidth;
> 
> Aqua/Cocoa:
> 
> 	    int avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
> 	    width = mbPtr->width * avgWidth;
> 
> According to Russell, these similar implementations produce very 
> different outcomes on the different platforms. The reason for this, I 
> believe, is the difference between font rendering engines on the two 
> platforms. His suggested fix, under Aqua, is to increment the width by 
> some specified amount, which, I'm inferring, would make the Aqua 
> implementation look more like the X11/Unix implementation visually. 
> (Haven't tested it.)

Is is possible that the width (in pixels) on unix applies to the text 
region of the widget, whereas on MacOS X the width in pixels applies to 
the whole widget (including the checkbox for a checkbutton, the menu 
indicator for a menubutton, etc.)?

If the width was in pixels, I would agree that widgets look different on 
different platforms, live with it.

But in this case width is in characters, and (until Tk 8.5) it meant 
that the widget could display approximately that many characters. That 
is a very sensible, simple and self-consistent meaning.

My suggested workaround is rather crude. I'd rather see it done more 
accurately. But I feel very strongly that this should be fixed in Tk, 
not inside the code every user of Tk uses.

Adrian: you mentioned that you have a more sophisticated workaround. 
Would you be willing to post it?

Since the option for specified width is supported, why not support it 
properly and in a way that is easy to use cross-platform? Fixing it in 
one place allows:
- Doing it right once
- Simpler code for people using Tk to write cross-platform scripts

You say that we shouldn't use width, but it used to work just fine and 
it would be pretty easy to make it work fine again.

I'm disappointed to see this change in direction for Tk. I maintain a 
python application that has to be functional (not necessarily beautiful) 
on unix, MacOS X and possibly Windows. Tk 8.4 worked well for that 
purpose. One code base did everything with only a bit of 
platform-specific code. The conversion to Tk 8.5 has been much more 
complicated than I ever dreamed. If I had not long ago wrapped most Tk 
widgets in wrapper classes I would have been in terrible trouble.

I thought incorporating ttk was a great idea for Tcl/Tk: those who 
wanted native looking widgets could use ttk and live with having only a 
few configurable parameters (a safe minimum set that worked on all 
platforms). But I never realized that the old cross-platform widgets 
were going to become so platform-specific as well.

Another issue like this that Kevin mentioned is menubutton colors. For 
some reason on MacOS X the bg config parameter sets the foreground, but 
only if fg has never been set. Huh? How can that possibly be reasonable? 
It sounds like something out of Catch-22. Would you really want to 
document such bizarre behavior? if bg cannot set the background color 
then for heavens sake ignore it, don't have it *maybe* set the 
foreground color!!! But it's a feature, not a bug, so it won't be fixed.

-- Russell

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

[Kevin W. <kw...@co...>]

On 11/28/12 7:29 PM, Adrian Robert wrote:
> Has the possibility been eliminated that there is a bug in the Tk/Cocoa-specific portion of the underlying Tk_TextWidth() implementation that causes a wrong result?  I fixed one bug in TkpMeasureCharsInContext() a while back and there could well be other issues elsewhere.

Hadn't thought of that. What bug number was the MeasureCharsinContext? 
I'd like to take a look.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

[Kevin W. <kw...@co...>]

On 11/28/12 4:20 PM, Adrian Robert wrote:
> I think if it's possible for Tk to support a widget option consistently across platforms it should do its best to do so.  What is or isn't best programming practice is one thing, but the API is kind of like a contract, that allows cross-platform applications to be written without the need for a lot of if-then's to handle different environments.

I certainly agree with this in principle. And, indeed, the internal 
implementation of calculating menubutton width is very similar on both 
Unix and Aqua (didn't check Windows):

Unix:

	avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
     .....
	width = mbPtr->width * avgWidth;

Aqua/Cocoa:

	    int avgWidth = Tk_TextWidth(mbPtr->tkfont, "0", 1);
	    width = mbPtr->width * avgWidth;

According to Russell, these similar implementations produce very 
different outcomes on the different platforms. The reason for this, I 
believe, is the difference between font rendering engines on the two 
platforms. His suggested fix, under Aqua, is to increment the width by 
some specified amount, which, I'm inferring, would make the Aqua 
implementation look more like the X11/Unix implementation visually. 
(Haven't tested it.)

I may be wrong here, but this strikes me as the wrong approach. Is the 
goal to have Tk fit in reasonably well on the Mac, and to take advantage 
of native API's to do so, or is to preserve cross-platform compatibility 
and visual consistency regardless of the contortions to the C API on a 
specific platform? Historically the practice has been the former: the Tk 
API is mapped to the underlying native API as much as possible, but 
without forcing it to conform when it's illogical (or impossible) to do so.

Hence Tk buttons on the Mac ignore a number of flags, such as -bg, 
because the native button cannot be configured this way. In another 
example, both a -bg and a -fg flag on a menu entry only configure the 
foreground because the background cannot be configured under Aqua menus; 
the rationale was, I presume, to configure what could be configured. 
(This is from another bug report Russell filed, 3588636, which I have 
declined to implement because it would break code in the Tk demo on the 
Mac.)

If a workaround to these issues can be implemented at the script level, 
I think that makes a lot more sense. Implementing these kinds of changes 
at the C level not only ignores a lot of past history in terms of Tk's 
practices, but it also risks pushing the C API more in the direction of 
spaghetti code. To be honest, there are few enough of us who understand 
Tk's C API's standard implementation (my understanding of it still has a 
lot of room for improvement); it's a bad idea to put in a lot of 
exceptions and workarounds to that API.

Aside/rant: I still can't believe that the new edition of the Osterhaut 
book blithely omits documentation of Tk's C API because so few people 
work on it. What a foolish, shortsighted decision. There's no way to 
attract developers to the toolkit if its C API is impossible to learn 
from available resources. Thank God for Brent Welch's book.

Back to the question at hand. I believe Russell's problem can be solved 
at the script level, and therefore, that's where it's best solved.

--Kevin
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com