Menu
▾
▴
pythoncard-users
|
From: <bra...@om...> - 2005-03-29 22:57:43
|
I'm beginning to spend more time using PythonCard during the course of
work,
and...so far, so good. I'm glad to have a tool like this available for
Python, and
I'm grateful to Kevin and the other contributors for their work on
PythonCard and all
the help I'm getting on the mailing list. When my skill level improves, I
hope to help
in whatever way I can.
One of the things I really like about PythonCard is the HyperCard-like
event
handling hierarchy.
Another thing I like is that PythonCard wraps a lot of wxPython stuff
that I'm not ready to take on yet, but still allows me to use wxPython in
small
ways when I need to. In that respect, I think of PythonCard as
wxTrainingWheels.
But in other respects, PythonCard is a powerful IDE whose features I am
still
learning about.
For the 1.0 release, I vote for sticking closely to the .81 release but
fixing some
of the Resource Editor glitches. It would be nice to have new features but
stability
of the API is very important to me. That said, maybe some small
improvements
and refinements can be added without upsetting the apple cart. In
particular,
I'm wondering if the Resource Editor can be improved without significantly
changing PythonCard's underlying structure.
On the other hand, there is one big feature that I'm hoping can be in the
1.0 release
-- the PageBackground (wxNotebook). This is in the .81 release, but it
seems to
be in an experimental stage. I'd like to have some of the kinks worked out
and
have good documentation for it. The ability to create a tabbed interface,
with tabs
inside of tabs, is vital to the kinds of applications I'm going to be
working on.
The splitter interface seems less important to me.
I've been saving up a list of ideas for improvements in PythonCard, some
of which may be
best suited for a much later release. Maybe this stuff is obvious to those
who have
been using PythonCard for awhile, but it can't hurt to mention them....
* ability to add parameters to childWindow and have them show up in the
backgrounds
on_initialize
* Create a new Text Entry dialog which allows for multiple input fields,
so you don't
have to build a custom dialog for that feature. Maybe it takes a
list of
fieldnames as a parameter.
* Placing text into widgets requires string values. It would be nice to
have type
coersion of primitives handled automagically, as it was in
HyperCard.
Even better, it would be nice to have them return values of their
original
type when accessed.
* Resource Editor:
* unpredictable about resizing some widgets. I'd like to see more
consistent
resizing behavior.
- this is worse on Mac, hopefully will improve w future
wxWidgets
- new users are scared off by flaky Resource Editor
behavior
- if we can't fix this short term, we should warn new
users
- not to think the rest of PythonCard is flaky, because it
isn't.
* when you click a widget, it shouldn't move. It should only move
when you
hold down the mouse for a noticeable time. As it stands,
I keep accidentally moving widgets.
* ability to select multiple multiple widgets and move them as a
group
* with multiple widget select, could also have an Alignment tool
ala FileMaker
* format painter, similar to FileMaker 6+
1. select a widget, and choose "Format Painter" from menu
2. the cursor changes to a paintbrush
3. any widget you click takes on the color and font
properties
4. press ESC to get out of format painter mode
*An alternative to format painter concept is copy/paste
properties idea
* Property Editor needs to be brought to the fore when the main
Resource Editor
window is selected (I get tired of having to re-invoke
Property Editor
when I'm switching between apps)
* Ability to delete widget by pressing delete key
(mine doesn't work under Mac or WinXP)
* Notebook widget easier to use
Maybe a Notebook property to hold a list of resource
module names,
and tab titles. Then the tabs would automatically appear,
just like
multicolumn list columns.
You could even store the resource for each tab inside main
window resource
* a nice clever UI for specifying tab order.
FileMaker's approach to this isn't bad, but may be too
difficult
in the short term. Maybe a simple "Tab Order" dialog
listing
text entry widgets and allowing them to be reordered.
Also, tab order should be unrelated to layer level
* default font property for the background resource which
contained widgets
would inherit. This could be specified in the GUI for bknd
properties
* Tool to convert a resource with statically placed widgets to sizer-based
layout,
and then back again. Ideally this could be done in Resource
Editor...
Another idea is the use of little "spring" meta-widgets similar to
Mac OS X
interface builder. These little springs keep the edge of a widget
near the
side of the window.
|
|
From: Bruce L. <Bru...@do...> - 2005-04-03 17:28:18
|
Kevin, I would like to see pythoncard more usable for making education resources and the single biggest difficulty for me was trying to make a stand alone application from by code that I could distribute easily to students who are general psychology students with limited computer skills (not enough to install and use python in my experience). Phil Edwards reportedly has some variety of solution to this as per his posting.. I think that "Learning Object" can be made easily with pythoncard but distribution of them in learning object repositories so other instructors can share the wealth is turning out to be a serious problem. The only other long distance solution is to try to code everything in javascript but that is a big step back from what you have done with pythoncard that I will press for easy distribution functionality of stand alone programs. Thanks for all the progress and dedication - truly inspiring Cheers Bruce -- Homepage: http://Bruce-Landon.douglas.bc.ca Landonline: http://landonline.edutools.info Weblog: http://radio.weblogs.com/0101747/ |
|
From: Schollnick, B. <Ben...@xe...> - 2005-04-04 12:54:19
|
Bruce, > I would like to see pythoncard more usable for making=20 > education resources and the single biggest difficulty for me=20 > was trying to make a stand alone application from by code=20 > that I could distribute easily to students who are general=20 > psychology students with limited computer skills (not enough=20 > to install and use python in my experience). Phil Edwards=20 > reportedly has some variety of solution to this as per his posting.. That is not a OpenSource, Python, or PythonCard failing.... If you do not wish your students or "other people" to be forced to install python and/or WxPython/PythonCard then you need to decide how to deal with that. There are two ways that I am aware of to deal with this. I have used both with my software and not had any significant problems. 1) McMillian Installer... Web Site is down, but the software is still available although unsupported on the Windows side per the Author.... =20 2) Py2Exe - Currently supported, not quite as polished as McMillian's installer but is still under development. The only con is that the Documentation is very sparse. Both of these packages allow you to bundle up your python software into a Windows executable file, with *no* dependencies..... So your students would not need to install any other software. Combine that with InnoSetup, a free Windows Installer application, and you can have your software installed with next to no issues..... > I think that "Learning Object" can be made easily with=20 > pythoncard but distribution of them in learning object=20 > repositories so other instructors can > share the wealth is turning out to be a serious problem. =20 I am not quite following you here.... A "Learning Object" is your application???=20 Distributing software can be as difficult as you make it. Especially on the Windows platform, dealing with the registry, etc. But it seems like you are making this into a larger problem than it is. Python is extremely portable, even more so with McMillian's Installer or Py2EXE. If you wish to try either Installer or Py2EXE feel free to ask if you need assistance. - Benjamin |
|
From: Sells, F. <fr...@ad...> - 2005-04-25 12:30:07
|
I am a PythonCard beginner, having developed a single-window simple app that is going into production. I previously developed a dragon-droppings gui builder for motif in the 90's. Many of my comments are based on that. However some core differences between Motif and wxWindows may make those comments invalid. I concur with Kevin's ideas and deleted his text where I have nothing to add for brevity. A. Pythoncard runtime support. 4. Event hierarchy.=20 Possible alternative: widget property has event-name <=3D> user-defined-name pair. Only events specified here are available to the application. All events go to a central handler which provides a great debug node and not all that much overhead. The application registers for named events with a call like PyCardEventHandler.registerForEvent(user-defined-name, python-callable). Benefits include: same method can handle multiple, similar events, fewer methods=3D=3Dcleaner code. A pretty-print routine can show all widgets that generate events. There can be multiple registrants for one event (calling order needs to be deterministic, i.e. in order registered) 5. Additional compound widget. - a static text "label" and a text field=20 good idea; most common use is label:control so you need some way to define the default spacing so a bunch can be placed in a column with the labels and data entry fields properly lined up. Anticipate need for one label and several data entry fields on a single row like city-state-zip. B. Geometry managements (aka sizers, resizing, etc.) We had a simple grid (default to 100x100) with "attachment properties" on each widget. If both right and left edge of widget were attached, it would move and resize with window resize, etc. To simplify the use of attachement, we had an attachment dialog that had 4 sets of identical "attaching controls" arranged at North, South, East, West. Combined with multiple widget select, you could attache left and right sides of a bunch at once, then go back and individually set top,bottom. It was not as elegant as most UI builders, but it was easy (the product was, after all, "ezX") New Feature Request: Need to be able to specify containers either in same file or different file to control multiple widgets at once. Handy for a "mode change" where one set of controls vanishes and another appears. Valuable to define this stuff in a different file/window and then import (perhaps only at runtime, use space holder in resource editor) so gui is more modular. New Feature Request: Need to be able to "invoke" PythonCard GUI from standard Python code, rather than subclass. Gives much greater flexibility to developer. --------------------------------------------------------------------------- The information contained in this message may be privileged and / or confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting the material from any computer. --------------------------------------------------------------------------- |
|
From: Alex T. <al...@tw...> - 2005-04-27 00:30:45
|
Sells, Fred wrote: >A. Pythoncard runtime support. > > >5. Additional compound widget. - a static text "label" and a text field >good idea; most common use is label:control so you need some way to define >the default spacing so a bunch can be placed in a column with the labels and >data entry fields properly lined up. > I still have no idea whether this would be - a single new component (probably too many values need to be attached ??) - a container with two components (probably too complex) - a resourceEditor convenience only - something else. I think the issue of getting a number of fields into columns and lined up well is just a specific case of alignment, and is going to be solved anyway, by either the ability to select multiple components (and then align and move them), or the ability to specify sizing / layout schemes, or both. > Anticipate need for one label and >several data entry fields on a single row like city-state-zip. > > But each of those would be a label : field on its own, wouldn't it ? What additional features would be needed in the "compound widget" to support this ? >B. Geometry managements (aka sizers, resizing, etc.) >We had a simple grid (default to 100x100) with "attachment properties" on >each widget. If both right and left edge of widget were attached, it would >move and resize with window resize, etc. To simplify the use of >attachement, we had an attachment dialog that had 4 sets of identical >"attaching controls" arranged at North, South, East, West. Combined with >multiple widget select, you could attache left and right sides of a bunch at >once, then go back and individually set top,bottom. It was not as elegant >as most UI builders, but it was easy (the product was, after all, "ezX") > > I think it's a little bit too simple for Pythoncard; it can't adequately handle some very simple cases (e.g. the scrolling text dialog, with one growable size textarea and one fixed size button below it), and I think that could put a lot of people off. >New Feature Request: Need to be able to specify containers either in same >file or different file to control multiple widgets at once. Handy for a >"mode change" where one set of controls vanishes and another appears. >Valuable to define this stuff in a different file/window and then import >(perhaps only at runtime, use space holder in resource editor) so gui is >more modular. > > Hmmm - interesting viewpoint. I want them in the resource editor more than I want them at runtime. I'd like to use them for moving groups of components around, selecting the subset to align or distribute, etc. Some of that can be done with "at the time" selection of multiple components, but I'd really like to make some of those collections "permanent" (e.g. all the address components in a contacts database). There is an experimental "container" component - but I think it was problematic (before my time :-) Making it a "first-class" component I think introduces some difficulties - need to get it into the event hierarchy, etc. I'd be content with a simple "list of other component names" which could be used to select a set of components in one operation - both in resource editor, and at run-time to enable the vanishing you described. Not sure what extra modularity you were looking for - I can't imagine a case where you wouldn't want to be able to see / modify these groupings in a layout editor. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005 |
|
From: Alex T. <al...@tw...> - 2005-11-02 13:48:50
|
Many months ago, there was some discussion about sizers, etc. One nice simple idea was suggested; at the time, I kind of "rejected" it because there are some simple things it didn't get quite right. But recently I decided there were more things it could do right - and it was very simple. So I implemented something loosely based on that thread in the simpleSizer which I added to PythonCard in the last 2 or 3 months; when I was doing that, I couldn't find the original email thread, so I didn't remember who had suggested it, and couldn't properly thank Fred for suggesting it. But today I stumbled over it - so here is a belated attribution of the idea .... thanks Fred. (And I realize my memory wasn't quite perfect, so it is much more "loosely" based than I had thought.) Sells, Fred wrote: >> B. Geometry managements (aka sizers, resizing, etc.) >> We had a simple grid (default to 100x100) with "attachment >> properties" on >> each widget. If both right and left edge of widget were attached, it >> would >> move and resize with window resize, etc. To simplify the use of >> attachement, we had an attachment dialog that had 4 sets of identical >> "attaching controls" arranged at North, South, East, West. Combined >> with >> multiple widget select, you could attache left and right sides of a >> bunch at >> once, then go back and individually set top,bottom. It was not as >> elegant >> as most UI builders, but it was easy (the product was, after all, "ezX") >> >> > I think it's a little bit too simple for Pythoncard; it can't > adequately handle some very simple cases (e.g. the scrolling text > dialog, with one growable size textarea and one fixed size button > below it), and I think that could put a lot of people off. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005 |
|
From: Phil E. <ph...@li...> - 2005-03-31 21:15:03
|
On Tue, 2005-03-29 at 23:56, bra...@om... wrote: > Another thing I like is that PythonCard wraps a lot of wxPython stuff > that I'm not ready to take on yet, but still allows me to use wxPython > in small > ways when I need to. In that respect, I think of PythonCard as > wxTrainingWheels. This, in my humble opinion, sums up nicely the greatest strength of PythonCard in its current form. > For the 1.0 release, I vote for sticking closely to the .81 release > but fixing some > of the Resource Editor glitches. It would be nice to have new features > but stability Likewise. The only things which really spring to mind in the current release are: 1. nailing the window geometry differences between Windows, Linux and MacOS 2. there's a problem with radiogroup components not displaying properly in either the resource editor or the running application 3. list components can't be selected in the resource editor 4. button dragging doesn't work in the resource editor My usual working environment is such that I tend to code/test on both Linux and Windows at the same time, so 1, 3 and 4 don't bother me too much - anything which I can't do on Linux I do under Windows instead. Item 2 could do with being fixed though. Could someone else using Linux try a radiogroup component in the resource editor and see what happens with both horizontal and vertical orientation? -- Regards Phil Edwards Brighton, UK |
|
From: Bo G. <bo...@sy...> - 2005-04-01 15:24:58
|
Phil Edwards wrote: >2. there's a problem with radiogroup components not displaying properly >in either the resource editor or the running application > > > Speaking of radio groups, any time I have a radio group present, the resource editor behaviour for left-right arrow keys is to change the default radio group value. It would be less noticable if it only happened when the radio group is selected, but that's the behaviour when any component is selected, effectively making the left-right arrow keys useless in the resource editor whenever there's a radio group present. I like to use the arrow keys to move components around in small increments, so I find it fairly annoying. |
|
From: Kevin A. <al...@se...> - 2005-04-04 17:01:34
|
On Apr 1, 2005, at 7:24 AM, Bo Green wrote: > Phil Edwards wrote: > >> 2. there's a problem with radiogroup components not displaying >> properly >> in either the resource editor or the running application >> >> > > Speaking of radio groups, any time I have a radio group present, the > resource editor behaviour for left-right arrow keys is to change the > default radio group value. It would be less noticable if it only > happened when the radio group is selected, but that's the behaviour > when any component is selected, effectively making the left-right > arrow keys useless in the resource editor whenever there's a radio > group present. I like to use the arrow keys to move components around > in small increments, so I find it fairly annoying. > Bo, which platform are you working on? I can look into this on Mac and Windows, but not Linux/GTK; if you're using Linux, specify whether it is a GTK1 or GTK2 build of wxPython. I suspect what is happening is that the problem platform has a compound control and the focus doesn't behave the way it should. I can probably add an explicit setFocus() call to go along with the display of the sizing handles and that will get rid of the problem, but I need to know if this is something Phil, Andy, or another GTK user will need to double-check after I check in the change. ka |
|
From: Bo G. <bo...@sy...> - 2005-04-04 17:30:24
|
Kevin Altis wrote: > On Apr 1, 2005, at 7:24 AM, Bo Green wrote: > >> Phil Edwards wrote: >> >>> 2. there's a problem with radiogroup components not displaying properly >>> in either the resource editor or the running application >>> >>> >> >> Speaking of radio groups, any time I have a radio group present, the >> resource editor behaviour for left-right arrow keys is to change the >> default radio group value. It would be less noticable if it only >> happened when the radio group is selected, but that's the behaviour >> when any component is selected, effectively making the left-right >> arrow keys useless in the resource editor whenever there's a radio >> group present. I like to use the arrow keys to move components around >> in small increments, so I find it fairly annoying. >> > > Bo, which platform are you working on? I can look into this on Mac and > Windows, but not Linux/GTK; if you're using Linux, specify whether it > is a GTK1 or GTK2 build of wxPython. I suspect what is happening is > that the problem platform has a compound control and the focus doesn't > behave the way it should. I can probably add an explicit setFocus() > call to go along with the display of the sizing handles and that will > get rid of the problem, but I need to know if this is something Phil, > Andy, or another GTK user will need to double-check after I check in > the change. > > ka This was observed while in Windows. I am sometimes using Mac as well, but not since I added the radio group. Thanks. Bo |
|
From: Bernie H. <ber...@ut...> - 2005-04-04 17:38:56
|
Also regarding the radio buttons - (Mac, 10.3 python 2.3 (self-installed) pythoncard .81) When I change the buttons from vertical to horizontal, and then reload the resource file it loads them as vertical, and I have to manually click on them to get them back to horizontal. Only happens for me when I specify the size rather than (-1,-1). I realized the difference is in the ordering in the resource file. When I manually change the resource file so that for each radio component the alignment is above size, I don't get this behaviour. (and yes, group select or some lasso function would be VERY much appreciated). Take Care, BERNiE I received a message from Kevin Altis at approximately 4/4/05 12:01 PM. Above is my reply. > On Apr 1, 2005, at 7:24 AM, Bo Green wrote: > >> Phil Edwards wrote: >> >>> 2. there's a problem with radiogroup components not displaying >>> properly >>> in either the resource editor or the running application >>> >>> >> >> Speaking of radio groups, any time I have a radio group present, the >> resource editor behaviour for left-right arrow keys is to change the >> default radio group value. It would be less noticable if it only >> happened when the radio group is selected, but that's the behaviour >> when any component is selected, effectively making the left-right >> arrow keys useless in the resource editor whenever there's a radio >> group present. I like to use the arrow keys to move components around >> in small increments, so I find it fairly annoying. >> > > Bo, which platform are you working on? I can look into this on Mac and > Windows, but not Linux/GTK; if you're using Linux, specify whether it > is a GTK1 or GTK2 build of wxPython. I suspect what is happening is > that the problem platform has a compound control and the focus doesn't > behave the way it should. I can probably add an explicit setFocus() > call to go along with the display of the sizing handles and that will > get rid of the problem, but I need to know if this is something Phil, > Andy, or another GTK user will need to double-check after I check in > the change. > > ka > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users -- |
|
From: <bra...@om...> - 2005-04-01 01:18:41
|
Brad Allen wrote > * Ability to delete widget by pressing delete key > (mine doesn't work under Mac or WinXP) I'd like to amend this: the delete key actually does work in resource editor; what I should have said was the backspace key. As a Mac guy, I'm not used to the distinction between the backspace key and the delete key. The backspace key has no other function in resource editor, right? I vote to let it do the same thing as the delete key. |
|
From: Bernie H. <ber...@ut...> - 2005-04-01 02:44:44
|
Ni! Although I don=B9t like to gripe about small stuff, this has actually been a consistent accident for me =AD I have selected a component (so the little squares are around the corners). I go to edit its properties and I hit delete while in a text field. It asks me if I would like to delete the component Note that it only happens when a specific component is selected. If no components are selected =8Cdelete=B9 works as expected inside text fields. [might this be mac specific or a general bug? also working on a mac] Love this program, developing a pretty big app right now in no time flat. The resource editor is great. Take Care, BERNiE I received a message from bra...@om... at approximately 3/31/05 8:17 PM. Above is my reply. >=20 > Brad Allen wrote=20 >> > * Ability to delete widget by pressing delete key >> > (mine doesn't work under Mac or WinXP) >=20 > I'd like to amend this: the delete key actually does work in resource edi= tor; > what I should have said was the backspace key. As a Mac guy, I'm > not used to the distinction between the backspace key and the delete key. >=20 > The backspace key has no other function in resource editor, right? > I vote to let it do the same thing as the delete key. |
|
From: <bra...@om...> - 2005-04-01 03:30:42
|
SSBzZWUgeW91ciBwb2ludC4gTWF5YmUgdGhlIGRlbGV0ZSB3aWRnZXQgc2hvcnRjdXQgc2hvdWxk IGJlIA0KY29tbWFuZC1CYWNrc3BhY2UgKGFuZCBjb21tYW5kLURlbGV0ZSkuIA0KDQoNCnB5dGhv bmNhcmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IHdyb3RlIG9uIDAzLzMxLzIw MDUgMDg6NDQ6MTMgDQpQTToNCg0KPiBOaSENCj4gDQo+IEFsdGhvdWdoIEkgZG9u4oCZdCBsaWtl IHRvIGdyaXBlIGFib3V0IHNtYWxsIHN0dWZmLCB0aGlzIGhhcyBhY3R1YWxseSANCj4gYmVlbiBh IGNvbnNpc3RlbnQgYWNjaWRlbnQgZm9yIG1lIOKAkyANCj4gSSBoYXZlIHNlbGVjdGVkIGEgY29t cG9uZW50IChzbyB0aGUgbGl0dGxlIHNxdWFyZXMgYXJlIGFyb3VuZCB0aGUgDQpjb3JuZXJzKS4N Cj4gSSBnbyB0byBlZGl0IGl0cyBwcm9wZXJ0aWVzIGFuZCBJIGhpdCBkZWxldGUgd2hpbGUgaW4g YSB0ZXh0IGZpZWxkLg0KPiBJdCBhc2tzIG1lIGlmIEkgd291bGQgbGlrZSB0byBkZWxldGUgdGhl IGNvbXBvbmVudA0KPiBOb3RlIHRoYXQgaXQgb25seSBoYXBwZW5zIHdoZW4gYSBzcGVjaWZpYyBj b21wb25lbnQgaXMgc2VsZWN0ZWQuIElmIA0KPiBubyBjb21wb25lbnRzIGFyZSBzZWxlY3RlZCDi gJhkZWxldGXigJkgd29ya3MgYXMgZXhwZWN0ZWQgaW5zaWRlIHRleHQgDQpmaWVsZHMuIA0KPiAN Cj4gW21pZ2h0IHRoaXMgYmUgbWFjIHNwZWNpZmljIG9yIGEgZ2VuZXJhbCBidWc/IGFsc28gd29y a2luZyBvbiBhIG1hY10NCj4gTG92ZSB0aGlzIHByb2dyYW0sIGRldmVsb3BpbmcgYSBwcmV0dHkg YmlnIGFwcCByaWdodCBub3cgaW4gbm8gdGltZSANCj4gZmxhdC4gVGhlIHJlc291cmNlIGVkaXRv ciBpcyBncmVhdC4gDQo+IA0KPiBUYWtlIENhcmUsDQo+IEJFUk5pRQ0KPiANCj4gDQo+IA0KPiBJ IHJlY2VpdmVkIGEgbWVzc2FnZSBmcm9tIGJyYWQuYWxsZW5Ab21zZGFsLmNvbSBhdCBhcHByb3hp bWF0ZWx5IA0KPiAzLzMxLzA1IDg6MTcgUE0uIEFib3ZlIGlzIG15IHJlcGx5Lg0KDQo+IA0KPiBC cmFkIEFsbGVuIHdyb3RlIA0KPiAgPiAgICAgICAqIEFiaWxpdHkgdG8gZGVsZXRlIHdpZGdldCBi eSBwcmVzc2luZyBkZWxldGUga2V5IA0KPiA+ICAgICAgICAgICAgICAobWluZSBkb2Vzbid0IHdv cmsgdW5kZXIgTWFjIG9yIFdpblhQKSANCj4gDQo+IEknZCBsaWtlIHRvIGFtZW5kIHRoaXM6IHRo ZSBkZWxldGUga2V5IGFjdHVhbGx5IGRvZXMgd29yayBpbiByZXNvdXJjZSANCmVkaXRvcjsNCj4g d2hhdCBJIHNob3VsZCBoYXZlIHNhaWQgd2FzIHRoZSBiYWNrc3BhY2Uga2V5LiBBcyBhIE1hYyBn dXksIEknbSANCj4gbm90IHVzZWQgdG8gdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIGJhY2tz cGFjZSBrZXkgYW5kIHRoZSBkZWxldGUgDQprZXkuIA0KPiANCj4gVGhlIGJhY2tzcGFjZSBrZXkg aGFzIG5vIG90aGVyIGZ1bmN0aW9uIGluIHJlc291cmNlIGVkaXRvciwgcmlnaHQ/IA0KPiBJIHZv dGUgdG8gbGV0IGl0IGRvIHRoZSBzYW1lIHRoaW5nIGFzIHRoZSBkZWxldGUga2V5Lg0KPiANCg0K |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X